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Abstract 

The  concept  of  object-based  control  is  extended  to  the  field  of  teleoperation, 
specifically  to  accomplish  the  task  of  spacecraft  docking  via  a  bilateral  manual  controller. 
An  object-based  controller  with  bilateral  feedback  controls  the  motion  of  the  grasped 
object,  not  the  trajectory  of  the  manipulator.  For  this  reason  it  can  be  designed  with 
feedback  that  is  intricately  linked  with  the  task  kinematics.  The  benefits  derived  from 
anthropomorphicity  and  force  feedback  are  possible  without  kinematically/geometrically 
similar  master-slave  systems,  complex  calibration  and  joint  mapping  schemes,  or 
expensive,  high  degree-of-freedom  force  reflection.  Object-based  control  is  ideal  for  low- 
level  telerobotic  interfaces. 

A  hand  controller  and  a  spacecraft  docking  simulation  are  designed  and 
constructed  to  demonstrate  object-based  bilateral  control.  The  dominant  task  objective  in 
spacecraft  docking  is  the  approach  to  a  target  vehicle  along  a  single  axis  of  motion. 
Several  methods  of  bilateral  feedback  linked  with  this  dominant  objective  are  proposed  in 
addition  to  simple  force  reflection.  One  method  involves  virtual  forces  and  another 
utilizes  velocity  reflection.  Each  method,  practical  only  with  object-based  control, 
enhances  the  man-machine  interface  by  providing  a  heuristic  method  of  manual  control. 
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TELEPRESENT  SPACECRAFT  DOCKING  WITH  OBJECT-BASED 
BILATERAL  CONTROL  (OBBC) 

I.  Introduction 

1. 1  Overview  This  thesis  proposes  a  new  control  method  for  teleoperation.  The  task 
chosen  to  demonstrate  this  new  control  architecture  is  spacecraft  docking.  Figure  1-1 
depicts  teleoperated  spacecraft  docking.  Major  docking  objectives  are  a  translational 
approach  to  the  target  vehicle  on  one  nominal  axis  with  man-in-the-loop  control  and  the 
quick  and  accurate  reduction  of  the  target  and  tracking  vehicle  separation  distance. 


TARGET  VEHICLE 


MASTER  HAND  CONTROLLER 

Figure  1-1.  Teleoperated  Spacecraft  Docking 
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1.2  Background  Space-based  applications  have  historically  required  man's  unique 
decision-making  skills  to  implement  contingency  operations  and  manual  control  (1,2, 3, 4). 
Additionally,  the  consensus  of  the  Department  of  Defense  (DOD),  major  universities  and 
industry  is  that  man-in-the  loop  control  will  play  a  vital  part  in  future  applications  that 
involve  highly  complex  tasks  in  extremely  dynamic  environments  (1).  Asa  result, 

NASA's  manned  and  unmanned  space  programs  are  based  on  the  premise  of  man-in-the- 
loop  control.  The  highly  automated  interplanetary  missions  such  as  Surveyor  III  and 
Viking  Mars  involved  manual  mission  modifications  and  ground-based  manipulator  arm 
control  (5).  The  Shuttle  Transportation  System's  robotic  arm,  as  well  as  the  orbital 
docking  accomplished  throughout  the  Gemini,  Apollo,  and  Apollo-Soyuz  programs, 
required  extensive  manual  control  (2,5,6).  The  future  requirements  of  space  flight  in  the 
era  of  the  space  station  will  depend  heavily  on  telemanipulated  spacecraft  docking  (5). 

The  history  of  spacecraft  docking  and  the  uncertainties  of  this  task  suggest  the  need  for 
the  complex  decision  capabilities  of  man,  while  the  need  for  quick  communication  without 
time  delay  and  the  hazardous  environment  in  which  this  task  is  performed  suggest  the  need 
for  autonomy.  But  at  least  until  significant  progress  in  automation  is  achieved,  critical 
decision-making  capability  and  emergency  contingency  operations  in  unpredictable 
environments  will  remain  a  human  responsibility. 

Past  and  current  spacecraft  rendezvous  operations  and  proximity  operations  require 
either  manual  override  or  hand  control  (7,25).  Astronauts  review  data  displayed  at 
consoles  and  either  punch  the  necessary  buttons  and  switches  for  automatic  control  or  use 
combinations  of  simple  interface  devices  similar  to  joysticks  to  perform  manual  spacecraft 
control  (2,7,25).  All  proximity  operations  require  crew  visual  queues  and  have  manual 
override  capability  perhaps  because  virtually  all  of  the  U.S.  and  former  Soviet  Union's 
attempts  at  docking  required  some  form  of  astronaut/cosmonaut  manual  control  (2,7,25). 

Review  of  the  research  establishes  three  categories  of  control  in  the  field  of 
telemanipulation.  They  are  distinguished  by  the  degree  of  man's  input  into  the  control 
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loop.  The  three  categories  are  executive,  supervisory,  and  manual  control.  Executive  and 
manual  control  are  easily  defined  because  the  represent  the  extremes  in  telemanipulation. 
Executive  control  is  basically  on/off  control  of  an  autonomous  robot  (4)  and  is  typically 
associated  with  the  term  telerobotics  (1).  Manual  control  is  total  human  control  and  is 
typically  associated  with  the  term  teleoperation  (1).  Supervisory  control,  a  term  coined 
by  Sheridan  (8),  is  more  difficult  to  precisely  define  because  it  combines  both  autonomous 
and  human  control  (5,8).  Because  it  involves  some  form  of  human  input,  it  too  is  often 
considered  teleoperation.  Supervisory  control  similar  to  the  telerobotic  extreme  implies 
human  input,  which  augments  pre-programmed  computer  control  (6,8).  Supervisory 
control  similar  to  the  teleoperation  extreme  implies  computer  input  which  augments 
human  manual  control  (8).  The  degree  to  which  the  interface  device  provides  a  human 
operator  with  realistic  information  from  the  task  environment  is  telepresence  (1,5).  Each 
broad  category  of  control  implies  that  the  human  operator  is  physically  separated  from  the 
task  environment,  necessitating  a  man-machine  interface  device.  This  interface  device  is 
referred  to  as  a  master  controller. 

Since  Ray  Goertz  created  the  world's  first  electrical  master-slave  manipulator  in  the 
1950's  at  the  Argonne  National  Laboratory  (3,5),  two  master  controller  types  have 
conclusively  emerged:  geometrically/kinematically  identical  master-slave  controllers 
(hereafter  referred  to  as  master-slave  controllers)  and  hand  controllers  (9).  Emphasis  has 
been  on  the  master-slave  controllers  (10),  probably  because  designers  seeking 
ergonomically  enhanced  man-machine  interface,  have  turned  to  anthropomorphicity 
(1,4, 10)  and  force  reflection  (1 1).  Anthropomorphicity  and  high  degree  of  freedom 
(DOF)  force  reflection  are  predominantly  identified  with  master-slave  controllers.  Force 
reflecting  hand  controllers  have  been  limited  to  miniaturized  replica  robots  (5).  In  other 
words,  traditional  force  reflecting  hand  controllers  are  just  miniaturized  versions  of  the 
master-slave  controllers.  Hand  controllers  have  made  strides  only  because  of  their 
compactness.  The  need  for  this  trait  is  particularly  evident  in  space-based  operations 
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where  orbital  work  space  is  at  a  premium  (4,9, 12).  The  question  of  utility  versus  cost  of  a 
force  reflecting  hand  controller  has  limited  the  use  of  force  reflection  in  hand  controller 
application  (10).  Still,  force  reflecting  hand  control  is  being  pursued  (12,13)  and  is  a 
design  specification  for  the  free  world's  future  space  station.  The  space  station  has  been 
the  main  force  behind  this  technology  for  the  past  decade  (5). 

Research  reveals  many  control  theories  that  track  actual  slave  motion  to  the  desired 
motion.  Common  control  concepts  include  position  and  force  control.  More  recent 
methods  are  hybrid  position-force  control  and  impedance  control  (5).  The  foundation  of 
the  research  in  this  thesis  is  object  impedance  control,  a  concept  and  theory  introduced 
and  developed  by  Schneider  and  Cannon  (14).  This  concept  focuses  on  the  control  of  the 
object  and  not  the  kinematics  of  the  manipulator.  The  authors  proposed  that  object-based 
control  is  an  extremely  efficient  technique  due  to  instinctual  control  and  transparent 
manipulator  dynamics.  If  applied  to  teleoperation,  the  instinctual  control  and  transparent 
manipulator  dynamics  would  have  three  effects  on  a  telemanipulation  system.  First,  there 
is  a  need  for  shared  control  and  increased  autonomy.  As  a  result,  the  basic  operation 
requires  little  or  no  training  because  control  is  reduced  to  (at  most)  three  simple 
translations  and  rotations  in  space,  which  are  skills  humans  accomplish  routinely  many 
times  per  work  day  (1,4).  Manipulator  motion  is  automatically  generated  by  the  computer 
based  on  the  commanded  object  motion.  Secondly,  the  physical  characteristics  of  the 
master  controller  need  not  be  anthropomorphic  or  geometrically/kinematically  similar  to 
the  slave.  Instead,  the  controller  can  be  similar  to  the  grasped  object  and  can  provide 
DOF  control  equal  to  that  required  by  the  object.  And  thirdly,  the  feedback  needed  for 
bilateral  control  becomes  easier  to  implement,  no  longer  dependent  on  complex 
mathematical  joint-mapping  transformations,  and  can  be  designed  kinematically  similar  to 
the  task. 

Up  to  now,  little  research  has  been  done  in  this  area.  Dr.  Nat  Durlach  of  MIT 
introduced  and  researched  Tool  Handle  Teleoperation  specifically  for  the  field  of  tele- 
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surgery.  This  method  allows  a  surgeon  to  manipulate  a  surgical  instrument  mounted  to  a 
robot  as  if  there  was  a  handle  attached  to  the  instrument  (15).  Most  recently,  Dr.  Paul 
Michelman  and  Dr.  Peter  Allen  of  Columbia  University  have  proposed  object-space 
teleoperation  (16).  They  use  a  simple  input  device  to  control  elementary  rotation  and 
translation  motion  of  a  Utah/MIT  dexterous  hand.  The  input  device  commands  are  based 
on  the  grasped  object  space,  rather  than  joint  position  space,  which  is  the  traditional 
method  to  control  motion  of  the  dexterous  hand. 

The  telepresence  provided  by  a  master  controller  is  achieved  mainly  through  the 
coupling  of  visual  feedback  with  bilateral  control,  the  two-way  communication  of  position 
and  force  information  between  the  user  and  the  task  environment  (17, 18).  Research 
indicates  that  telemanipulated  task  completion  is  up  to  50%  quicker  when  some  kind  of 
force  information  is  returned  to  the  operator  (8,12,13,16,19)  and  shows  that  force 
reflection  used  for  bilateral  control  is  extremely  effective  if  the  operator  desires  to  control 
[contact]  forces  in  the  task  environment  ( 1 1 , 1 7, 1 8) .  T raditional  teleoperation 
architecture  derives  feedback  in  one  of  two  ways  (17).  In  the  first  method,  the  effect  of 
object/environment  interaction  on  each  slave  joint  is  directly  measured,  and  impedance  or 
hybrid  position/force  control  is  used  to  force  the  corresponding  actuated  joints  of  the 
master  to  track  these  slave  joints.  Master-slave  symmetry  makes  this  method  practical  but 
dictates  master  controller  geometric  design.  The  second  method,  which  is  required  for 
hand  controllers,  is  to  form  complex  Jacobians  that  mathematically  transform  slave  end- 
effector  forces  into  master  joint  torques.  For  either  method,  slave/environment  forces  are 
corrupted  by  the  compliance  of  the  systems,  while  task  and  grasped  object  dynamics  are 
completely  neglected.  Furthermore,  the  complex  mathematical  transformations  make  it 
impossible  to  orchestrate  this  information  so  that  it  can  be  used  to  provide  a  more 
instinctual  feedback. 

This  thesis  proposes  a  new  teleoperation  concept  called  object-based  bilateral 
control  (ODBC),  and  demonstrates  its  implementation  with  a  spacecraft  docking 
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simulation.  OBBC  extends  the  object  control  theory  of  Schneider  and  Canon  (14)  to 
teleoperation  and  enhances  operator  telepresence  via  the  addition  of  bilateral  control. 
OBBC  provides  object-space  control  to  facilitate  simple  and  realistic  reflection  of  the 
interaction  of  the  object  with  the  environment  while  transparently  controlling  the  motion 
of  the  slave.  Complex  schemes  to  transform  end-effector  dynamics  to  joint-space  torques 
for  effective  bilateral  control  are  not  required;  instead,  the  feedback  is  tailored  to  exploit 
the  task's  dominant  kinematic  objectives.  OBBC  makes  1-DOF  tactile  feedback  a 
practical  and  useful  design  trait.  Additionally,  this  type  of  control  simplifies  the 
correlation  of  multiple  DOF  data  for  feedback  via  a  controller  with  a  single  or  low-level 
DOF  feedback  capability. 

Spacecraft  docking  is  an  ideal  task  for  OBBC  implementation  because  dominant 
kinematic  objectives  are  clear  and  easily  integrated  into  the  master  controller  design. 
Additionally,  the  use  of  the  OBBC  master  controller  is  compatible  with  the  practice  of 
using  hand  controllers  in  spacecraft  proximity  operations. 

The  following  chapter  compares  object-based  teleoperation  architecture  with  the 
current  architectures  and  makes  general  comparisons  of  each.  The  design  characteristics 
and  operational  traits  of  the  master  controller's  four  operational  modes  are  also  discussed. 
Presently,  AFIT  does  not  possess  a  hand  controller  that  offers  bilateral  control  capability; 
therefore,  a  prototype  master  controller  has  been  designed  and  fabricated  to  enable  OBBC 
implementation.  The  description  of  this  hardware  is  the  subject  of  chapter  3.  The  master 
controller  is  designed  bilaterally,  that  is,  it  is  used  to  input  commands  for  the  six  degrees 
of  freedom  (3  translational  and  3  rotational)  of  a  spacecraft  and  it  is  actuated  for  feedback 
in  one  degree  of  freedom,  specifically  for  spacecraft  approach  axis  feedback.  The  simple 
integration  of  two  special  types  of  heuristic  feedback  designed  with  task  kinematic 
similarity  is  discussed.  Both  methods  utilize  virtual  feedback  that  includes  a  shared 
control  between  the  operator  and  the  computer  thereby  increasing  the  overall  system 
autonomy.  Chapter  4  describes  the  overall  OBBC  system  controller  design  and  its  link 
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with  the  graphical  spacecraft  docking  simulation.  Also  discussed  in  this  chapter  is  the 
OBBC  communication  network.  Standard  UNIX  C  programs  have  been  written  to 
perform  master  controller  serial  communication  and  ethemet  communication  between 
Silicon  Graphics,  Sun  Sparc  workstations,  and  a  real-time  microprocessor.  Chapter  5 
documents  results  recorded  during  spacecraft  docking  simulation  with  the  four  operational 
modes  of  the  prototype  OBBC  system.  Chapter  6  summarizes  conclusions  and 
recommendations  about  the  thesis.  Finally,  the  appendices  supply  design  drawings,  code 
listings  and  flowcharts,  and  simulation  operation  instructions. 

1.3  Principal  Accomplishments  The  principal  accomplishments  of  this  research  are: 

•  development  and  demonstration  of  an  object-based  bilateral  teleoperation  concept,  a 
concept  unique  to  the  fleld  of  teleoperation. 

•  fabrication  of  a  6-degree-of-freedom  hand  controller  with  1-degree-of-freedom 
feedback  to  the  operator,  offering  bilateral  control 

•  demonstration  of  the  utility  of  multi-axis  to  single-axis  feedback  for  bilateral  control, 
specifically  in  spacecraft  docking 

•  development  and  implementation  of  two  bilateral  controllers  unique  to 
telemanipulation  and 

•  the  design  of  a  low-level  telemanipulation  communication  hub. 
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n.  OBBC  Concepts  and  Current  Implementation  Methods 


2. 1  OBBC  Telemanipulation  Architecture  Research  implies  that  a  paradigm  has  evolved 
with  the  control  architecture  of  telemanipulation.  The  physical  design  of  the  slave  has 
dictated  the  foundation  of  the  overall  system  control  theory,  the  physical  design  of  the 
master  controller,  and  the  design  and  implementation  of  the  system's  feedback. 
Additionally,  due  to  the  benefits  derived  from  ergonomics,  designers  have  been  forced  to 
incorporate  anthropomorphic  and  high  DOF  force  reflection  characteristics  in  master 
controller  design,  putting  further  limitations  on  the  slave  design.  This  paradigm 
necessitates  complex  calibration  and  joint  mapping  schemes,  geometrically/kinematically 
identical  master-slave  systems,  and  detailed  knowledge  of  task  and  manipulator.  It  has 
also  forced  the  emergence  of  basically  two  types  of  master  controllers.  The  two  controller 
types  are  force  reflecting  hand  controllers  (FRHC)  and  the  geometrically/kinematically 
identical  master-slave  controllers  with  force  reflection.  The  basic  control  architecture  for 
these  type  of  controllers  is  illustrated  in  Figure  2- la. 

The  OBBC  challenges  this  paradigm  because  the  control  theory  is  object  based; 
therefore,  the  operator  controls  the  motion  of  the  object,  not  the  slave.  The  OBBC 
implementation  used  in  this  thesis  to  perform  teleoperated  spacecraft  docking 
demonstrates  a  master  controller  physical  design  not  restricted  by  a  need  for  geometric 
symmetry.  OBBC  also  demonstrates  bilateral  control  that  utilizes  feedback  designed  to 
exploit  the  docking  task.  Furthermore,  ergonomic  benefits  are  demonstrated  without 
anthropomorphism.  The  proposed  general  architecture  is  seen  in  Figure  2- lb. 
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Figure  2- la.  TRADITIONAL  TELEOPERATION  ARCHITECTURE 


Figure  2-lb.  ODBC  TELEOPERATION  ARCHITECTURE 


Figure  2- 1 .  Block  Diagrams  of  Teleoperation  Architectures 

Figure  2-1  illustrates  the  difference  between  object-based  control  and  the 
traditional  teleoperation  architecture  defined  by  Anderson  and  Spong  (18).  Ideally,  for 
the  traditional  architecture,  the  desired  effect  of  the  slave  (vg)  is  controlled  to  equal  the 
input's  effect  on  the  master  (vj^),  and  the  reflected  force  from  the  environment  (fg)  is 
controlled  to  equal  the  force  sensed  by  the  operator  (f^).  The  object  and  task  dynamics 
are  neglected  when  implementing  traditional  teleoperation.  For  the  OBBC  architecture, 
the  desired  effect  of  the  object  (vq)  is  controlled  to  equal  the  input  on  the  master  (v^)  via 
automatic  computer  generated  slave  input  (vg).  In  Figure  2- lb  the  slave  box  in  the  OBBC 
architecture  is  drawn  dotted  to  illustrate  that  the  slave  dynamics  are  transparent  to  the 
operator.  It  is  also  important  to  note  that  object  forces  need  not  be  manifested  through 
the  slave  before  communication  back  to  the  master  controller. 

The  terms  in  the  teleoperation  architectures  are  related  to  the  spacecraft  docking 
task  (pictured  in  Figure  1-1  of  chapter  1)  in  the  following  discussion.  The  human  operator 
or  teleoperator  is  an  astronaut  or  ground  personnel  manning  the  master  controller.  The 
master  controller  is  the  interface  device  that  provides  input  for  the  control  of  a  remote 


slave  and  object.  The  slave,  specifically  for  docking,  is  the  attitude  control  and  propulsion 
subsystems  of  the  object  or  tracking  vehicle  at  a  remote  environment.  Finally,  the 
environment  is  the  approach  and  interaction  between  the  tracking  and  target  vehicles. 

2.2  Qualitative  Comparison  of  Teleoperation  Techniques  Table  2-1  compares 
information  obtained  from  the  design  and  implementation  of  OBBC  with  existing  master 
controllers'  characteristics.  Automatic  control  is  included  in  this  table  because  it 
represents  the  ultimate  evolution  in  telemanipulation,  otherwise  known  as  telerobotics. 

The  assessed  characteristics  for  FRHC,  master-slave  and  autonomous  controllers  are 
extracted  from  4,5,10,1 1,12,13,16,17,20,  and  21  and  are  divided  into  the  two  categories 
of  engineering  and  human  factors.  In  Table  2-1,  the  OBBC  and  Autonomous  controllers 
are  shaded  to  highlight  their  similarity.  The  letters  "H",  "M",  and  "L"  stand  for  high, 
medium  and  low  respectively  and  represent  the  degree  to  which  each  characteristic  was 
manifested. 


Controller  Characteristics 

FRHC 

Master- 

Slave 

OBBC 

Antoiio- 

mous 

engineering 

factors 

Design  simplicity 

L 

H 

H 

h 

Ease  of  object/environment 
feedback  implementation 

L 

M 

H 

M 

H 

Anthropomorphic 

dependency 

L 

H 

U 

IHI 

Tailored  to  task  dynamics 

L 

L 

xt 

JdL 

Universal 

H 

L 

M 

L 

Cost 

H 

M 

L 

human 

factors 

Ease  of  use 

M 

M 

rf 

JuL 

H 

M 

L 

L 

Requires  coupling  w/  visual 
fib 

H 

H 

L 

Ergonomic  feedback 

M 

L 

H 

Table  2-1.  Qualitative  Comparison  of  Teleoperation  Techniques 
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General  assessments  could  not  be  made  about  certain  controllers  for  some  of  the 
characteristics,  thus  their  respective  table  entries  are  left  blank.  The  table  illustrates  two 
key  points.  It.compares  the  human  and  engineering  characteristics  of  each  controller  to 
show  that  the  OBBC  controller  is  a  specialized  FRHC  which  makes  the  controller  more 
autonomous  but  less  universal. 

2. 2  Prototype  OBBC  Mode  Characteristics  The  prototype  OBBC  system  is  designed 
with  four  operational  modes.  All  modes  provide  six  degree  of  freedom  (6-DOF)  control 
of  a  tracking  vehicle  in  a  spacecraft  docking  simulation.  Detailed  information  about  the 
docking  simulation  is  documented  in  chapters  3  and  4.  The  baseline  mode  offers  only 
unilateral  control  with  no  feedback  other  than  the  visual  feedback  inherent  to  the  graphical 
simulation.  The  remaining  three  modes  additionally  offer  1-DOF  bilateral  control 
reflecting  information  about  the  axis  of  approach.  The  four  modes  are  as  follows: 

•  Mode  1  ;  unilateral  control 

•  Mode  2  :  force  reflection 

•  Mode  3  :  virtual  force  reflection 

•  Mode  4  ;  electronic  funneling 

Table  2-2  is  a  comparison  of  the  prototype's  operational  modes  and  a 
recommended  alternative  mode.  The  table  summarizes  the  characteristics  derived  from 
each  mode's  feedback  design  and  implementation  discussed  in  sections  2.2.1  through 
2.2.5.  As  in  Table  2-1,  the  characteristics  are  assigned  a  grade  of  "H",  "M  "or  "L". 
Assessments  are  made  from  the  actual  implementation  of  the  four  operational  modes.  The 
alternative  mode's  assessment  is  hypothesized. 

2. 3. 1  Mode  1  -  Unilateral  Control.  The  unilateral  control  mode  enables  the 
teleoperator  to  provide  the  6-DOF  input  required  for  control  of  the  tracking  vehicle  during 
docking  simulation.  No  feedback  is  returned  to  the  operator  in  this  mode.  The  operator 
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uses  only  visual  feedback  to  accomplish  the  spacecraft  docking.  The  target  vehicle  was 
assumed  to  have  been  designed  with  the  necessary  compliance  to  produce  acceptable 
impact  forces  for  a  range  of  nominal  terminal  closure  rates.  This  mode  is  most 
representative  of  current  spacecraft  proximity  operations  in  that  it  is  performed  via  a  hand 
controller  without  bilateral  control.  One  could  postulate  that  a  highly  skilled  and  practiced 
operator  using  unilateral  control  with  visual  feedback  could  eventually  perform  the  task 
optimally,  without  the  need  for  special,  non-visual  feedback. 

The  performance,  operation,  and  design  of  this  mode  is  used  as  the  baseline  for  the 
comparison  of  the  design  and  operation  of  the  other  master  controller  modes.  The  human 
factor  traits  in  this  discussion  are  based  on  initial  operation  of  the  master  controller  in  its 
respective  modes. 

2. 3.2  Mode  2  -  Force  Reflection.  The  major  kinematic  objective  in  spacecraft 
docking  is  a  translational  approach  along  only  one  axis  of  motion  (2).  In  mode  two,  force 
reflection,  the  approach  axis  force  resulting  from  object/environment  (i.e.  tracking  and 
target  vehicle)  interaction  is  reflected  back  to  the  operator.  During  the  docking  task,  force 
on  the  approach  axis  due  to  the  environment  is  non-existent  unless  contact  between  the 
target  and  tracking  vehicles  occur.  Upon  contact,  either  from  task  completion  or  an 
unplanned  collision,  contact  force  on  the  approach  axis  is  modeled  as  the  force  generated 
by  a  simple  spring  that  has  sufficient  force-length  to  allow  the  operator  to  "feel"  contact 
for  sufficient  time  to  sense  the  rate  of  closure  and  to  make  required  adjustments.  This 
type  of  feedback  would  be  extremely  effective  for  docking  if  the  target  vehicle  has  a 
recoiling  probe  that  is'extended  during  docking  to  absorb  impact  forces. 

During  operation  in  this  mode,  the  operator  feels  no  interaction  until  actual  contact 
is  made  with  the  target  vehicle  at  task  completion.  Thus,  force  reflection  indicates  only 
that  contact  has  occurred,  regardless  of  whether  this  contact  is  from  a  successful  docking 
or  from  a  catastrophic  collision.  Though  the  operator  easily  recognizes  task  completion, 
force  reflection  information  does  nothing  to  enhance  the  operator's  pre-contact 
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performance  because  the  operator's  ability  to  react  is  limited  by  the  limitations  on  the 
spring  force-length.  Details  about  this  mode  and  its  integration  into  the  ODBC  prototype 
controller  are  found  in  section  4.2.3. 1 . 

2. 3. 3  Mode  3  -  Virtual  Force  Reflection.  A  unique  feedback  method  is  mode 
three,  virtual  force  reflection.  Virtual  force  reflection  employs  a  virtual  spring  to  provide 
the  teleoperator  with  feedback  throughout  the  task  duration.  The  computer  generates  this 
virtual  spring  environment  that  continuously  interacts  with  the  tracking  vehicle  along  the 
approach  axis.  The  object/environment  interaction  is  monitored  by  the  computer  and 
reflected  back  to  the  operator  via  the  actuated  master  controller.  The  operator  must  apply 
forces  to  the  master  controller  to  overcome  a  growing  virtual  force.  If  the  applied  forces 
are  greater  than  the  reflected  force,  the  operator  can  feel  the  master  controller  move  in  the 
nominal  docking  direction.  The  virtual  force,  calculated  in  object-space,  grows  linearly  as 
the  tracking  vehicle  approaches  the  target  on  the  approach  axis.  Mode  three  is  designed 
with  a  100m  linear  virtual  spring,  but  any  spring  length  and  force/displacement  relationship 
could  have  been  substituted.  The  virtual  spring  of  mode  3  extends  from  the  docking  port 
of  the  target  vehicle.  The  operator  can  apply  forces  at  the  master  controller  only  sufficient 
enough  to  equal  the  maximum  force  of  the  virtual  spring,  making  impact  with  the  target 
vehicle  theoretically  impossible. 

The  virtual  force  is  designed  to  moderate  the  negative  effect  of  the  feedback  on  the 
task  performance,  so  the  feedback  is  reflected  only  when  motion  is  commanded  with  the 
manual  controller,  acting  like  a  dead  man  trigger.  This  mode  demonstrates  how  the 
OBBC  concept  permits  the  simple  manipulability  of  the  data  derived  from 
object/environment  interaction,  transforming  it  into  ergonomic  feedback  by  selecting  only 
useful  information  for  return  to  the  teleoperator.  The  feedback  thus  allows  the  operator  to 
concentrate  on  other  task  objectives. 

During  simulation,  the  motion  along  the  axis  of  approach  is  automatically 
regulated  as  the  tracking  vehicle  approaches  because  the  virtual  force  limits  the  input 
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commanded  at  the  master  controller,  leaving  the  operator  free  to  align  the  remaining 
translational  and  rotational  degrees  of  freedom.  The  commanded  translation  over  the 
separation  distance  is  extremely  fast  and  returns  continuous  feedback  to  the  teleoperator. 
While  the  operator  remains  dependent  on  visual  feedback  despite  virtual  force  reflection, 
this  mode  enhances  the  manual  control  of  the  docking  simulation  and  demonstrates  the 
utility  of  single-axis  force  reflection.  Details  about  this  mode's  integration  into  the 
prototype  OBBC  controller  are  found  in  section  4.2. 3. 2. 

2. 3. 4  Velocity  Reflection  with  Electronic  Funneling.  OBBC  makes  it  possible  to 
propose  two  methods  of  feedback,  the  previously  mentioned  virtual  force  reflection  and 
velocity  reflection  with  electronic  funneling.  These  methods  are  unique  to 
telemanipulation  because  OBBC  allows  the  feedback  design  to  integrate  the  major 
kinematic  objective  of  the  docking  task,  and  OBBC  facilitates  the  orchestration  of  all 
information  derived  from  object  and  environment  interaction.  The  second  unique 
feedback,  implemented  in  mode  4,  is  velocity  reflection  derived  from  fimneled  multi-axis 
object/environment  interaction.  Because  the  prototype  OBBC  hand  controller  is  object- 
based,  a  simulated  constant  spacecraft  velocity  can  be  reflected  back  to  the  master 
controller.  Approach  motion  of  both  the  object  and  the  master  is  prohibited  until  the 
operator  uses  the  master  controller  to  satisfy  position  and  orientation  constraints  on  the 
tracking  vehicle.  The  constraints  are  dictated  by  a  virtual  hypercone  originating  at  the 
docking  port  of  the  target  vehicle  and  centered  on  the  approach  axis.  If  all  constraints  are 
satisfied,  the  docking  approach  can  proceed.  The  operator  "feels"  the  approach 
proceeding  when  the  master  begins  to  move  at  a  constant  velocity  scaled  from  the  actual 
spacecraft  velocity.  The  master  controller  is  actuated  with  forces  derived  from  a  constant 
force  virtual  spring  that  exerts  a  force  on  the  master  on  the  nominal  docking  axis.  This 
force  is  actuated  at  the  master  only  when  a  hypercone  of  constraints  around  the  ultimate 
target  position  and  orientation  are  satisfied  and  only  when  motion  along  the  approach  axis 
is  commanded. 
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The  constraints  are  described  by  a  virtual  hypercone,  since  they  are  dependent  on 
information  from  all  six  degrees  of  freedom.  The  translational  constraints  of  the 
hypercone  are.  depicted  in  Figure  2-2.  The  virtual  hypercone  extends  out  from  the  nominal 
docking  position.  It  is  25m  in  length,  and  its  radius  at  any  given  point  is  dependent  on  the 
separation  distance  between  the  target  and  tracking  vehicle  along  the  axis  of  nominal 
docking  direction.  Thus  the  closer  the  tracking  vehicle  is  to  the  target  vehicle,  the  stricter 
the  tolerances  become  on  the  error  between  the  commanded  position  and  orientation  of 
the  tracking  vehicle  and  the  nominally  docked  position  and  orientation.  Inherent  in  this 


Figure  2-2.  Depiction  of  Translational  Hypercone  Constraints 

mode  is  a  shared  control  between  the  teleoperator  and  the  computer.  Motion  along  the 
approach  axis  is  handled  by  the  computer,  with  executive  control  dictated  by  the 
operator's  alignment  of  the  remaining  position  and  orientation  axes.  The  virtual  hypercone 
places  constraints  on  the  off-axes  data  to  "funnel"  the  object's  approach  to  a  pre-planned 
target  position.  The  feedback  is  unique  to  teleoperation  because  it  is  derived  from  multi¬ 
axis  data  but  is  fed  back  to  the  teleoperator  via  single-axis  actuation  of  the  master 
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controller;  therefore,  both  the  approach  to  the  target  vehicle  and  the  multi-axis  feedback 
are,  in  a  sense,  funneled. 

During  the  simulation,  velocity  feedback  with  electronic  funneling  allows  quick 
and  accurate  task  completion  when  coupled  with  visual  feedback.  Small  simulation 
modifications  could  make  task  completion  with  this  mode  possible  even  without  visual 
feedback.  Teleoperator  control  is  enhanced  with  the  use  of  various  input  filtering 
functions  programmed  for  the  spaceball  which  modify  the  programmed  velocity  or 
sensitize  off-axis  input,  thereby  increasing  the  effectiveness  of  the  mode.  Final  docking 
position  and  attitude  are  completely  accurate  but  spacecraft  terminal  closure  rate  is  high. 
Safety  concerns  related  to  this  high  terminal  velocity  can  be  addressed  by  modifying  the 
ultimate  target  position,  which  can  be  accomplished  by  modifying  the  hypercone 
constraints. 

The  limited  range  of  motion  on  the  prototype  hand  controller's  feedback  actuation 
system  forced  the  interruption  of  the  docking  simulation  and  hampered  the  evaluation  of 
this  feedback  mode.  Details  about  this  mode's  integration  into  the  prototype  OBBC 
controller  are  found  in  section  4. 2. 3. 3. 

2.S.5  Mode  5  -  Virtual  Environment.  A  virtual  environment  is  suggested  as  an 
alternative  master  controller  mode,  designed  to  reflect  position,  velocity,  and  (virtual) 
interaction  forces  to  the  teleoperator.  The  virtual  environment  is  practical  and  easily 
implemented  because  OBBC  sensors  at  the  object  provide  object-space  data.  This  mode 
would  require  the  implementation  of  the  optical  encoder  and  augmentation  of  its 
associated  processing  ftardware.  As  a  result,  closed  loop  motor  control  can  be  utilized. 
The  hand  controller  could  then  be  designed  with  position  references  which  are  calibrated 
to  match  actual  positions.  Position  commands  are  input  via  the  hand  controller,  and  the 
actual  position/velocity  is  bilaterally  returned  to  the  operator.  Virtual  forces  could  be 
reflected  to  complete  the  package.  The  controller  becomes  a  mini-virtual  environment, 
and  visual  feedback  is  no  longer  necessary  for  manual  control.  This  alternative  mode 
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which  represents  nominal  telepresence,  is  discussed  for  comparative  purposes  and  was  not 
implemented. 


FEEDBACK  DESIGN 

Mode  1 

Mode  2 

Mode  3 

Mode  4 

Mode  5 

ergonomically  designed 
tailored  to  task  kinematics 
ease  of  implementation 
derived  from  multiple  axis 
data 

L 

L 

M 

H 

H 

L 

L 

M 

H 

H 

H 

H 

M 

M 

M 

H 

H 

TASK  PERFORMANCE 

completion  speed 
completion  accuracy 
contingency  capability 
(manual) 

dependency  on  visual 
feedback 

L 

L 

H 

M 

H 

L 

L 

M 

H 

H 

H 

H 

H 

H 

H 

H 

H 

H 

M 

L 

Table  2-2.  Comparison  of  Implemented  and  Alternative  Feedback  Modes 
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m.  Description  of  Prototype  Hardware  for  OBBC 


3. 1  Overview  To  investigate  and  demonstrate  OBBC,  a  six  degree  of  freedom  (6-DOF) 
master  hand  controller  actuated  to  provide  feedback  had  to  be  designed  and  constructed. 
The  fabricated  master  controller  is  a  position  control  interface  device  for  a  spacecraft 
docking  simulation.  The  complexity  and  cost  of  multi-axis  feedback,  as  well  as  the  nature 
of  the  docking  task,  suggested  that  a  master  controller  with  feedback  in  only  the  nominal 
docking  direction  would  supply  the  teleoperator  with  sufficient  feedback  for  enhanced 
telepresence.  The  prototype  master  controller  is  pictured  in  Figure  3-1 .  The  four  major 
components  of  the  controller  are  the  actuator,  the  servo-amplifier  and  power  supply,  the 
CIS  Dimension  6  spaceball,  and  the  spaceball  platform  and  actuator  casing. 
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Figure  3-1.  Prototype  OBBC  Master  Controller 


During  the  simulation,  the  operator  envisions  the  master  controller  spaceball 
platform  as  the  spacecraft  in  the  simulation  display  and  inputs  changes  to  the  spacecraft 
position  and  attitude  by  imparting  a  force  or  torque  on  the  spaceball  knob,  acting  as  if 
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using  his  hand  to  position  the  spacecraft  itself.  The  actuator  casing  always  remains 
immobile,  but  in  modes  2  through  4,  described  in  the  previous  chapter,  the  approach  axis 
force  sensed  at  the  spacecraft  from  its  interaction  with  the  environment  is  converted  to  a 
proportional  torque  that  is  applied  to  the  platform  actuator.  The  operator  then  "feels" 
one  axis  of  spacecraft/environment  force  (or  motion  in  mode  4)  with  his  hand. 

3.2  Actuator  The  actuator  is  a  Globe  24VDC  electric  motor,  selected  because  it  was 
back-driveable  and  already  in  AFIT's  possession.  The  actuator  generates  the  necessary 
reflected  feedback.  Attached  to  its  motor  shaft  is  a  double  cable  spool,  which  is  designed 
to  simultaneously  reel  in  and  out  six  gauge  metal  cable.  The  drive  cable  is  secured  to  each 
end  of  the  spaceball  platform  and  pulls  on  the  platform  to  move  it  in  either  direction  along 
the  tracks,  the  direction  being  dependent  on  the  direction  of  the  reflected  force.  The 
spaceball  platform  is  immobile  due  to  the  mechanical  impedance  of  the  drive  system  unless 
voltage  is  supplied  to  the  actuator.  Also  attached  to  the  motor  is  a  Hewlett  Packard  500 
count  resolution  optical  encoder. 

3.3  Servo-amplifier  and  power  supply  The  servo-amplifier  is  a  Copley  Controls  Corp. 
300  Series  Amplifier  powered  with  a  Series  600  unregulated  DC  power  supply,  requiring  a 
standard  120V  AC  outlet.  The  amplifier  is  used  as  a  voltage  to  current  converter  and  is 
operated  in  the  flat-gain  mode,  requiring  a  reference  or  control  voltage  of  ±  75mV. 

Specific  amplifier  information  can  be  obtained  from  its  user  manual  (22).  Unforced 
movement  of  the  spaceball  platform  requires  at  least  a  ±  35mV  reference  voltage  signal  to 
the  servo-amplifier  which  overcomes  the  impedance  of  the  drive  system. 

3.4  CIS  Dimension  6  Spaceball  The  CIS  Dimension  6  Spaceball  (Dim  6)  contains  a  6- 
DOF  optical  force  sensor  integrated  into  a  spherical  knob.  It  is  this  force  sensor  that  is 
used  to  modify  the  tracking  vehicle's  position  vector.  A  standard  RS-232  connection  and 
a  null  modem  device  allows  serial  interface  with  a  Silicon  Graphics  IRIS  Indigo 
workstation  (SGI).  The  Dim  6  has  dip  switch  selectable  communication  parameters,  the 
settings  for  which  are  found  in  Appendix  F. 
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In  addition  to  the  optical  force  sensor,  the  Dim  6  has  a  keypad  complete  with  8 
function  buttons  and  3  transmission  modes.  Function  buttons  are  user  definable,  and  these 
functions  are  defined  in  section  4.2. 1 .  Figure  3-2  depicts  the  buttons  used  for  the  three 
transmission  modes,  labeled  as  "TRA",  "DOM",  and  "ROT".  When  initially  powered  up, 
the  Dim  6  is  in  default  mode  and  will  transmit  forces  sensed  in  all  six  degrees  of  freedom. 
The  teleoperator  can  use  the  TRA  button  to  transmit  only  translational  inputs  and  the 
ROT  button  to  transmit  only  rotational  inputs.  The  DOM  button  transmits  only  the 
dominant  force  sensed  by  the  spaceball  and  can  be  used  in  conjunction  with  any 
transmission  mode. 
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Figure  3-2.  Dim  6  Keypad 

Additional  information  about  the  Dim  6  can  be  obtained  from  its  user  manual  (26). 
3.5  Spaceball  Platform  and  Actuator  Casing  The  Dim  6  provides  the  required  6-DOF 
command  input  to  the  spacecraft,  but  by  itself  is  incapable  of  reflecting  feedback  to  the 
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teleoperator.  Thus  a  platform  capable  of  "frictionless"  motion  in  the  ±  x  (approach  axis) 
direction  was  constructed  with  aluminum  and  four  ball-bearing  wheels.  The  Dim  6  is 
mounted  to  the  platform,  and  the  drive  cable  of  the  actuator  is  attached  at  both  ends.  The 
platform  glides  on  tracks  machined  into  the  top  of  the  actuator  casing,  prohibiting  out  of 
plane  motion.  The  range  of  translational  travel  is  up  to  three  inches.  The  actuator  casing 
provides  a  housing  for  the  actuator  motor  and  spool,  as  well  as  the  servo-amplifier  and  the 
power  supply.  Additionally,  the  casing  provides  a  pulley  interface  for  the  connection 
between  the  actuator  cable  and  the  spaceball  platform. 
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IV.  Prototype  Object-based  Bilateral  Controller  Design 


4. 1  Overview  Several  programs  were  required  to  perform  overall  system  control.  The 
server  ffobmc.c  program  of  appendix  B,  in  conjunction  with  the  frobmc.gsl  program  of 
appendix  C,  performs  two  main  functions.  First  the  programs  serve  as  a  folly  resolved 
position  control  system  that  performs  tracking  of  a  desired  position  command  input. 
Secondly,  these  programs  function  together  as  a  master  control  system  that  processes 
operator  input  from  a  master  controller  operating  in  one  of  four  operational  modes  and 
actuate  the  master  controller  to  return  feedback  to  the  operator.  A  secondary  function  of 
server_frobmc.c  allows  user-  selectable  scaling  of  hand  controller  input.  The  simulation 
driven  by  frobmc.gsl  with  input  from  server_frobmc.c  displays  the  approach  of  a  6-DOF 
rigid  body  spacecraft  to  an  immobile  target  vehicle.  The  main  visual  display  provided  to 
monitor  docking  is  a  cockpit  view  and  is  complete  with  dual  crosshairs  to  enhance  visual 
feedback.  A  set  of  crosshairs  is  attached  to  each  docking  point  on  the  tracking  and  target 
vehicles.  A  second  display  provides  a  top  view  of  the  docking.  The  target  vehicle  is  a 
space  station  constructed  from  graphics  provided  by  Deneb  Robotics  for  Interactive 
Graphics  for  Robotic  Interface  Program  (IGRIP).  The  tracking  vehicle  is  modeled  after 
the  Precision  Orbital  Tracking  Vehicle  (POTV),  the  spacecraft  of  Lawrence's  thesis  (23). 
Both  vehicles'  graphics  and  the  basic  simulation  design  were  originally  programmed  by 
Tom  Bridgman  (24).  User  keyboard  interface  is  required  to  input  the  tracking  method  and 
operational  mode  preferences,  and  the  initial  separation  distance  necessary  to  initiate  the 
simulation.  The  server  frobmc.c  coding  is  accomplished  in  standard  UNIX  C,  and  a 
complete  listing  as  well  as  a  flowchart  can  be  found  in  Appendix  B.  This  software  is 
intricately  linked  with  the  Graphics  simulation  code,  which  drives  the  visual  display  of  the 
docking  on  an  SGI  Indigo  workstation.  The  frobmc.gsl  coding  is  written  in  Graphics 
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Simulation  Language  (GSL)  for  IGRIP,  and  a  complete  listing  as  well  as  its  flowchart  can 
be  found  in  Appendix  C. 

4.2  Prototype  OBBC  Architecture  The  function  of  the  OBBC  control  system  is  to 
force  the  position  of  the  object  to  track  the  position  input  at  the  master  controller  while 
simultaneously  allowing  the  master  controller  actuation  system  to  track  the  influence  of 
the  environment  on  the  object.  Thus  the  OBBC  teleoperation  system  can  be  considered  a 
two-port  network.  One  port  represents  the  interaction  between  the  operator  and  the 
master  controller,  while  the  other  port  represents  the  interaction  between  the  spacecraft 
(object)  and  its  environment.  The  object/environment  port  must  be  created  to  allow  the 
slave  (spacecraft  attitude  control/propulsion  subsystems)  dynamics  to  remain  transparent 
to  the  operator.  One  way  to  represent  the  OBBC  two-port  architecture  is  illustrated  in 
Figure  4-1  and  is  discussed  in  the  following  sections. 


Figure  4-1.  Prototype  OBBC  Architecture 
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4.2. 1  Master  Control.  To  move  the  simulated  object  (tracking  vehicle),  the 
teleoperator  imparts  a  force  or  a  torque  in  the  desired  translational  or  rotational  direction 
on  the  hand  controller  knob.  This  input  forms  the  master  input  vector  and  is  made  up  of 
three  forces  and  three  torques: 


m  =[/.  fy  /.  t.  ty  if 

The  server  frobmc.c  program  then  translates  this  into  meters/degrees  with  the  mapping 
fiinction,  Kj^.  Kjju  maps  forces  and  torques  exerted  on  the  control  knob  to  values 
between  0  and  1  meters  and  between  0  and  1  degrees  respectively. 

If  operating  the  master  in  mode  1,  the  mapped  input  is  simply  summed  with  the 
current  desired  position  command  vector.  A  keyboard  input  of  the  initial  desired  position 
is  required  before  the  simulation  will  commence.  Operation  in  modes  2  and  3  sums  the 
mapped  input  with  the  current  desired  position  command  vector,  as  well  as  with  the  force 
information  derived  from  the  object/environment  interaction.  In  mode  4  operation, 
server_frobmc.c  evaluates  a  flag  returned  from  frobmc.gsl.  This  flag  indicates  whether  or 
not  the  mode  4  constraints  are  satisfled.  When  the  constraints  are  satisfied,  the  desired 
command  vector  is  updated  with  a  constant  Im  input.  Unsatisfied  constraints  allow  the 
desired  command  vector  to  remain  unchanged.  The  updated  desired  position  command 
vector  is  made  up  of  three  translational  positions  and  three  relative  attitude  angles; 

Tdei  ^des  ^des  ^ des  ¥ des  ] 

At  simulation  initiation,  the  initial  desired  position  command  is  input  via  the  keyboard. 

Server_frobmc.c  enables  the  teleoperator  to  use  the  function  keys  on  the  keypad  of 
the  master  controller  to  modify  the  scale  and  sensitivity  of  the  commanded  input. 
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Function  button  #4  reduces  input  to  1/10  the  default  input  capability.  Depressing  button 
#5  cuts  commanded  input  of  the  off-axes  by  half  while  button  #8  doubles  the  input  of  the 
oflf-axes.  The.operator  can  double  the  input  of  the  approach  axis  with  button  #6.  Finally, 
the  input  can  be  restored  to  default  levels  with  button  #2.  Table  4-1  summarizes  the 
keypad  functions. 


Button  # 

Function 

2 

reset  all 

4 

0.  1  [fy  f^  ty  ty  t7l 

5 

0.5[fy  tx  ty  t^] 

6 

2fx 

8 

_ ^[fy  4  tx  ty  tz] _ 

Table  4- 1 .  Master  Controller  Keypad  Functions 

4.2.2  Slave  Position  Controller  Design.  The  updated  desired  position  command 
vector  becomes  the  input  to  a  slave  position  controller.  For  a  spacecraft,  this  slave 
controller  would  be  the  attitude  control  and  propulsion  subsystems.  The  design  of  the 
controller  (see  Figure  4-2)  is  borrowed  and  modified  from  a  thesis  by  Richard  E. 
Lawrence  (23).  This  design  includes  the  controller  system,  input,  pre-filter,  and  gain 
matrices  optimized  for  both  the  V-Bar  and  R-Bar  tracking  methods.  The  R-Bar  tracking 
method  is  an  approach  to  the  target  along  the  radius  vector  of  the  target  vehicle,  while  V- 
bar  tracking  is  an  approach  to  the  target  vehicle  along  a  horizontal  component  of  the 
target  vehicle's  tangential  velocity  vector  (25). 
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Figure  4-2.  Position  Controller  Block  Diagram 


The  vectors  and  matrices  in  Figure  4-2  are  defined  as  follows: 

r6xl  =  desired  position  command  vector  F  =  system  matrix 

u9xl  =  control  vector  G  =  input  matrix 

xl2xl  =  system  state  vector  H  =  output  matrix 

y6xl  =  output  position  vector  M  s  pre-filter  matrix 

K  =  controller  gain  matrix 

The  controller  code  utilizes  a  4th-order  Runge-Kutta  method  for  the  necessary 
integration  of  the  relative  equations  of  motion  and  is  extracted  from  a  program  by  Tom 
Bridgman  (24).  The  linearized  equations  of  motion  of  the  tracking  vehicle  relative  to  the 
target  vehicle,  as  well  as  the  non-gravitational  forces  and  moments,  are  completely  derived 
by  Lawrence  (23).  The  complete  set  of  both  translational  and  rotational  relative  equations 
of  motion  are  as  follows: 


26 


-  _  2  Px 

X  -  2ny  -  3n  X  =  — 
m 

(4.1) 

y  +  lnx  =  — 
m 

(4.2) 

z  +  n^z  =  — 

m 

(4.3) 

A{9-n(l>)  +  {C-B){n(l>  +  n^e)  = 

(4.4) 

7 

B{(p  +  nd)  +  (A  C)(n9  4n^<f>  )  = 

h 

(4.5) 

C(v~)  +  =M, 

F 

(4.6) 

where  F^,  Fy,  and  F2  are  non-gravitational  forces;  M^,  My,  and  are  non-gravitational 
moments;  n  =  yjGM^Ir^ ;  A,  B,  and  C  are  principal  moments  of  inertia  of  the  tracking 

vehicle;  m  is  the  mass  of  the  tracking  vehicle;  ro  is  the  magnitude  of  the  target  vehicle's 
position  vector;  and  r  is  the  magnitude  of  the  tracking  vehicles  position  vector. 

4.2.3  Object/Environment  Interaction.  The  slave  controller  output  position 
vector  y  is  used  by  ffobmc.gsl  to  drive  the  position  and  attitude  of  the  object  (tracking 
vehicle)  in  the  docking  simulation.  The  operator  then  uses  this  simulation  as  visual 
feedback.  At  this  point,  unilateral  master  control  (mode  1)  is  completely  described.  For 
the  remaining  operational  modes,  ffobmc.gsl  creates  a  simulated  environment  to  provide  a 
source  for  the  non-visual  feedback. 

4. 2. 3. 1  Mode  2  -  Force  Reflection.  In  mode  2,  the  force  on  the  axis  of 
approach  from  any  contact  between  the  tracking  and  target  vehicles  is  modeled  as  the 
force  of  a  linear  spring.  This  force,  limited  to  the  approach  axis  due  to  master  controller 
design,  is  calculated  in  object  space  as  described  in  Figure  4-1,  where  x^  is  the  position  of 
contact,  and  x  is  the  commanded  position  of  the  object  that  caused  the  contact.  Kg  is  a 
spring  constant  and  makes  the  force  proportional  with  fx.  The  resulting  object-based 
force  fg  X  is  summed  with  the  fx  input  sensed  at  the  master.  The  summed  force  is  then 
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converted  to  the  necessary  voltage  units  to  actuate  the  spaceball  platform  on  the  master 
controller. 

4. 2. 3. 2  Mode  3  -  Virtual  Force  Reflection.  In  mode  3 ,  the  source  of  the 
feedback  created  by  frobmc.gsl  is  a  virtual  spring.  The  operator  must  overcome  the 
virtual  force  generated  by  a  100m  long  virtual  spring  that  originates  from  the  target 
vehicle.  For  the  prototype,  this  virtual  spring  is  infinitely  wide  and  the  force  fg  x  is 
calculated  as  described  in  Figure  4-1,  where  lys  is  the  unforced  length  of  the  virtual 
spring.  As  before,  this  force  is  limited  to  the  axis  of  approach  because  it  is  this  axis  for 
which  feedback  is  available  at  the  master  controller.  Kyg  is  a  spring  constant  and  makes 
the  force  proportional  to  fx-  No  force  is  created  until  the  separation  distance  is  less  than 
the  100m  length  of  the  spring.  Furthermore,  the  force  is  fed  back  only  when  the 
teleoperator  makes  a  command  input  in  the  nominal  docking  direction  (fx  >  0).  The 
feedback  imparted  to  the  operator  by  the  master  is  the  sum  of  the  commanded  force  fx  and 
the  virtual  force  fg  x^  This  summed  force  is  then  converted  to  voltage  and  relayed  to  the 
manual  controller.  If  a  collision  with  another  part  of  the  target  vehicle  should  occur  in  this 
mode,  this  force  is  reflected  back  by  the  same  method  used  in  mode  two. 

4. 2. 3. 3  Mode  4  -  Velocity  Reflection  with  Electronic  Funneling.  In  mode  4, 
the  code  again  generates  an  environment  for  object  interaction  that  serves  as  the  source 
for  the  non-visual  feedback.  Unlike  the  previous  two  modes,  all  of  the  object's  position 
and  attitude  components  are  utilized  in  the  derivation  of  the  feedback.  A  hypercone  of 
off-axes  alignment  constraints  is  created  from  the  separation  distance  between  the  tracking 
and  target  vehicles.  As  can  be  seen  in  Figure  4-1,  the  feedback  is  only  possible  when  the 
constraints  C  of  the  virtual  hypercone  are  satisfied  by  the  ongoing  simulation  and  only 
when  the  operator  is  commanding  motion  in  the  nominal  docking  direction  (fx  >  0). 

The  constraints  C  are  explicitly  defined  below: 


28 


0.255 
|z- 2, 1  <0.255 
1^-^,  I  <0.2505 
<l>-(t>\<Q.lSQs 
Iv'- V^,|<0.25(^)5 


where  the  subscript  t  indicates  a  target  vehicle  variable  and  the  separation  distance  is  s  = 
(x-x^).  The  0.25  constant  was  arbitrarily  chosen.  The  constraints  were  specifically  made 
dependent  on  the  separation  distance,  tailoring  the  feedback  design  to  task  dynamics.  The 
constant  can  be  changed  to  make  the  constraints  more  stringent.  In  order  to  provide  a 
concrete  example  of  the  tolerances  created  by  the  constraints,  consider  two  vehicles  with  a 
separation  distance  of  12m.  The  translational  position  error  on  the  off-  axes  can  be  no 
larger  than  3m  and  the  attitude  angle  error  can  be  no  larger  than  3°. 

The  constraints  are  monitored  by  ffobmc.gsl  with  additional  visual  feedback 
provided  to  the  operator  if  the  constraints  are  not  satisfied.  This  additional  visual 
feedback  is  in  the  form  of  the  background  color  of  the  simulation  display  and  the  set  of 
crosshairs  representing  the  target  and  tracking  vehicles.  The  operator  adjusts  off-axes 
translational  positions  by  "superimposing"  the  tracking  vehicle  crosshairs  on  the  target 
vehicles  crosshairs.  The  background  color  of  the  cockpit  view  display  will  turn  green  if 
the  tracking  vehicle  with  respect  to  the  nominal  docking  attitude  is  off  in  yaw,  yellow  if  off 
in  pitch,  and  purple  if  off  in  roll.  Because  motion  of  the  tracking  vehicle,  and  thus  the 
master  controller,  is  only  permitted  when  the  software  verifies  that  all  constraints  are 
satisfied,  increased  system  autonomy  and  shared  control  is  implied. 

4. 3  Communication  Software  Communication  is  a  very  important  design  trait  for  a 
teleoperation  system  because  time  delay  is  a  major  problem  source  for  teleoperation  (18). 
Total  round-trip  communication  for  the  prototype  controller  is  less  than  1/5  of  a  second, 
which  causes  a  slight  discrepancy  between  the  visual  feedback  and  the  feedback  used  to 
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provide  bilateral  control.  The  communication  network  for  the  prototype  OBBC 
simulation  consists  of  the  basic  components  needed  to  perform  teleoperation  but  lacks 
realism  in  its  representation  of  all  components  necessary  for  true  remote  teleoperation. 
For  example,  the  displays  provided  for  the  visual  feedback  during  simulation  would 
actually  require  radio  communication  to  remote  cameras.  This  type  of  communication 
was  not  part  of  the  OBBC  simulation. 

The  communication  software  that  provides  the  necessary  teleoperation 
communication  to  support  the  data  flow  illustrated  in  Figure  4-3  is  written  in  standard 
UNIX  C  language.  A  complete  source  listing  can  be  found  in  appendix  D. 


Manual  Controller 


Object  and  Environment 


Communication 


Figure  4-3.  System  Data  Flow 

4. 3. 1  Ethernet  Communication.  The  central  hub  of  all  ethemet  communication  is 
OBBC_comm_hub.c  .  It  is  executed  on  a  Sun  Microsystems  SPARC  2  Workstation. 

This  hub  provides  communication  between  the  SGI  workstation  and  the  CHIMERA- 
operated  real-time  VME  microprocessor.  The  code  providing  the  communication  link  at 
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the  microprocessor  necessary  for  D/A  and  A/D  interface  with  the  manual  controller  is  the 
program  ff.c. 

4. 3. 2  Master  Controller  Input  Communication.  The  communication  software  also 
provides  serial  communication  between  the  SGI  workstation  and  the  CIS  Dimension  6 
spaceball  portion  of  the  master  controller.  Because  the  master  controller  control  is 
performed  in  the  same  location  as  the  creation  of  the  virtual  environment  and  the  control 
of  the  simulated  object,  this  communication  is  not  truly  indicative  of  remote  teleoperation. 
This  communication  satisfies  simulation  requirements,  but  again,  reality  would  require  a 
radio  communication  component  necessary  to  relay  information  between  the  master  and  a 
remote  object.  The  source  code  is  written  to  support  all  selectable  communication 
parameters  of  the  Dimension  6  spaceball. 

4. 4  IGRIP  Environment  The  Deneb  Robotics  IGRIP  software  provides  many 
interactive  tools  that  the  teleoperator  may  find  useful  during  the  simulation.  Three  that 
have  aided  in  a  successful  completion  of  the  docking  task  are  the  joint  values,  magnify, 
and  rotate  world  functions.  The  operation  of  these  tools  is  described  in  the  operation 
instructions  found  in  Appendix  E.  The  joint  value  fimction  allows  the  user  to  view  the 
tracking  vehicle's  translational  and  rotational  position  values.  The  magnify  tool,  when 
used  in  conjunction  with  the  rotate  world  tool,  allows  for  a  close  inspection  of  the  mating 
between  the  target  and  tracking  vehicles.  These  tools  can  be  used  to  enhance  the  views 
generated  automatically  by  frobmc.gsl. 
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V.  Demonstration  of  Prototype  Operation 


5.1  Task  Description  The  operation  of  the  prototype  ODBC  master  was  limited.  A 
simple  spacecraft  docking  simulation  was  used  to  demonstrate  the  functional  capability  of 
the  controller  in  each  of  its  four  modes.  In  each  case  the  tracking  vehicle  made  an  R-bar 
approach  to  the  target  vehicle  and  master  control  was  initiated  at  a  separation  distance  of 
15  meters.  No  attitude  angles  were  commanded.  The  approach  was  free  of  any  possible 
contingency  operation  and  accuracy  of  the  docking  position  at  task  completion  was  not 
recorded.  The  task  was  considered  complete  when  the  separation  distance  was  reduced  to 
1 5mm  or  less.  The  operator  was  expected  to  perform  the  task  as  accurately  as  possible 
and  achieve  a  small  terminal  velocity.  Table  5-1  summarizes  each  mode's  simulation 
performance. 


Characteristic 

Mode  1 

Mode  2 

Mode  3 

Mode  4 

Initial  separation  distance 

15m 

15m 

15m 

15m 

Tracking  method 

R-bar 

R-bar 

R-bar 

R-bar 

Maximum  velocity  (m/s) 

0.0047 

0.0071 

0.0114 

0.0165 

Velocity  at  task  completion  (m/s) 

0.0015 

0.0003 

0.0 

0.0 

Duration  (s) 

3800 

4920 

2320 

4360 

Table  5-1.  Master  Mode  Simulation  Summary 

5.2  Closure  Rate  Profiles  For  each  of  the  master  controller  modes,  tracking  vehicle 
velocity  was  recorded  to  illustrate  functional  differences.  Figure  5-1  shows  their 
separation  closure  rates.  These  plots  should  not  be  interpreted  as  an  evaluation  of  the 
controller  since  insufficient  controls  were  applied  during  data  collection.  Possible  controls 
would  have  included  such  factors  as  accuracy  at  task  completion,  skilled  or  unskilled 
operators,  task  duration  limits,  and  contingency  response.  The  results  are  specific  to  the 
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operator  and  could  change  even  if  rerun  due  to  their  sensitivity  to  operator  skill  and  style. 
For  all  modes,  manual  operation  was  initiated  at  3900  seconds  because  all  mode 
simulations  were  initiated  with  identical  initial  command  vectors.  The  profiles  for 
operation  in  modes  1  and  2  illustrate  each  mode's  sensitivity  to  operator  style.  The  mode 
1  profile  shows  a  non  aggressive  style  indicated  by  small  initial  commanded  velocities. 

The  operator  was  forced  to  command  input  near  task  completion,  resulting  in  a  terminal 
velocity  larger  than  any  mode.  In  contrast,  the  profile  recorded  for  mode  2  shows  an 
aggressive  operator  style  indicated  by  the  large  initial  commanded  velocities,  which 
resulted  in  a  slow  terminal  velocity. 

When  making  further  comparisons,  it  should  be  noted  from  Figure  5-1  that  the 
mode  4  zero  closure  rates  indicate  translational  corrections  in  the  off-axes.  The  mode  was 
designed  so  that  the  task  could  not  proceed  until  the  errors  in  the  alignment  of  the  lateral 
axes  were  corrected.  This  design  characteristic  allows  unequaled  accuracy  in  task 
performance.  Errors  in  the  lateral  translational  axis  at  task  completion  were  significantly 
less  than  those  of  any  other  mode.  In  fact,  a  perfectly  piloted  tracking  vehicle  with  mode 
4  operation,  could  achieve  significant  reductions  in  task  duration  due  to  its  high  constant 
velocity  input  (note  the  maximum  velocities  in  Table  5-1).  Neglecting  the  time  for  off- 
axes  correction  in  mode  4's  profiled  data,  task  duration  is  2520s. 

The  profiles  for  modes  3  and  4  show  no  velocity  at  task  completion,  indicating  that 
contact  between  the  tracking  and  target  vehicle  is  never  achieved.  This  is  possible  only 
because  the  sensors  are  assumed  to  be  perfectly  accurate  and  reliable. 
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Figure  5-1 ,  Spacecraft  Closure  Rates 
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VI.  Conclusion  and  Recommendations 


6. 1  Conclusion  Current  teleoperation  systems  are  based  fundamentally  on  the  slave 
that  manipulates  the  controlled  object,  and  master-slave  symmetry  is  either  required  or 
assumed  in  order  to  provide  enhanced  telepresence  to  the  operator  via  the  master 
controller.  Object-based  bilateral  control  (OBBC)  offers  a  new  control  concept  for 
teleoperation  and  for  master  controller  design.  The  benefits  of  anthropomorphicity  and 
bilateral  control  are  obtained  without  the  need  for  kinematically/geometrically  identical 
master-slave  systems,  complex  calibration  and  joint  mapping  schemes,  detailed  task  and 
manipulator  knowledge,  and  expensive  high  DOF  force  reflection.  Manipulator  motion  is 
transparent  to  the  user  and  automatically  generated.  Subsequently,  the  controller 
autonomy  is  increased,  thus  enhancing  task  performance  and  significantly  reducing  the 
operator's  required  training  for  the  task.  Both  the  master  controller  and  its  feedback  are 
tailored  to  the  task  and  designed  ergonomically  with  no  geometrical  limitations  imposed 
by  the  design  of  the  manipulator.  The  obviated  need  for  complex  joint  mapping 
transformations  implies  that  multiple  axis  feedback  can  be  selectively  reflected  to  a  low 
DOF  feedback  capable  controller,  making  single-axis  feedback  a  desirable  design  trait. 
Mode  3  of  the  prototype  controller  demonstrates  how  OBBC  can  be  used  to  increase  the 
utility  of  single-axis  feedback.  Furthermore,  OBBC  facilitates  the  orchestration  of  multi¬ 
axis  object/environment  information,  allowing  for  the  return  of  usefiil  information  to  a  low 
DOF  feedback  controller.  As  a  result,  practical  tactile  feedback,  like  the  velocity  feedback 
of  mode  4,  can  be  implemented  to  provide  enhanced  telepresence  without  dependency  on 
force  reflection. 

The  feasibility  of  the  telepresent  OBBC  architecture  and  the  utility  of  its  unique 
feedback  has  been  demonstrated  through  implementation  in  a  spacecraft  docking 
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simulation.  OBBC  application  is  not  limited  to  spacecraft  docking,  but  includes  aircraft 
munitions  loading,  micro-chemistry,  and  tele-surgery. 

6.2  Recommendations  OBBC  is  unique  because  its  control  is  performed  in  object- 
space,  and  its  design  utilizes  bilateral  control.  Though  object-based  teleoperation  has  very 
recently  been  demonstrated,  never  before  has  it  been  accomplished  with  bilateral  control. 
Object-based  teleoperation  is  in  its  infancy,  and  its  general  concept  deserves  further 
exploration. 

6.2.1  Feedback  Design.  With  OBBC,  feedback  is  not  just  a  means  to  provide 
heuristic,  natural  manual  control.  The  feedback  itself  is  designed  ergonomically.  Useful 
feedback  for  bilateral  control  is  not  limited  to  force  reflection.  Many  types  of  tactile 
feedback  can  now  be  practical  because  the  feedback  design  can  be  tailored  to  specific  task 
kinematics.  The  many  possibilities  of  feedback  design,  including  optimal  feedback 
"mixing"  and  selective  feedback,  are  the  most  significant  benefit  of  OBBC  and  should  be 
explored.  Specifically  to  the  thesis  work.  Mode  4  could  be  enhanced  by  substituting  the 
constant  force  spring  with  linearly  increasing  force  derived  similarly  from  the  off-axis 
deviation. 

6.2.2  Multi-axis  to  Single-axis  Feedback.  OBBC  has  demonstrated  the  utility  of  a 
single-axis  feedback  capable  controller  by  funneling  multi-axis  data.  This  idea  of 
"furmeled  feedback"  should  be  researched.  Master  controllers  designed  with  limited  DOF 
feedback  capability  could  significantly  reduce  their  cost.  The  potential  cost  savings  alone 
is  reason  enough  to  pursue  multi-axis  to  single-axis  feedback. 

6.2.3  Closed  Loop  Motor  Control.  The  feedback  actuation  on  the  prototype  hand 
controller  has  been  designed  with  an  open  loop  motor  control.  The  actuator  that  provides 
the  1-DOF  bilateral  control  is  equipped  with  an  optical  encoder.  The  communication 
software  has  been  designed  to  handle  this  required  communication  flow.  However,  the 
hardware  and  software  necessary  to  process  encoder  data  must  be  augmented.  Closed 
loop  motor  control  would  enhance  the  current  controller's  feedback  modes  by  providing 
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accurate  position  feedback  and  would  allow  additional  feedback  designs,  such  as  the 
virtual  environment  suggested  in  chapter  2,  to  be  more  intricately  coupled  to  the  task. 
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Appendix  A 


A.  1  Design  Drawings:  Spaceball  Platform  (cm,  not  to  scale) 


Figure  A-2.  Top  View  -  Spaceball  Platform 


Figure  A-3.  Front  View-  Spaceball  Platform 


A. 2  Design  Drawings:  Actuator  Casing  (cm,  not  to  scale) 


Figure  A-4.  Side  View  -  Actuator  Casing 


Figure  A-5.  Top  View  -  Actuator  Casing 


42 


Appendix  B 


B.  1  Prototype's  Server  Software:  Flowchart 


Figure  B- 1 .  Server  frobmc. c  Flow  Chart 


B.2  Prototype's  Server  Software:  Source  Code  Listing 


Sjc  9|C9|CSj(^^9{C«jC)|(3|C9jC9|C9|(9ft3|C  ^  ^  ^  ^  ^  3|C  SjC  ^  3jC  SjC  SjC  9|C  ?|C  ){C  ^  )|( 

*  Name:  PautWoznick,  Jul  94  * 

*  Server  frobmc.c  Adapted  from  code  provided  by  T.  Bridgman  * 

if  if 


*  Purpose:  The  purpose  if  this  program  is  to  implement  a 

*  4th  order  Runge-Kutta  routine  needed  to  solve 
* 

*  differential  equations.  Specifically,  the  routine  will 

*  perform  motion  generation  computations  for  a  6  DOF 

I" 

*  rigid  body  (r-bar,  and  v-bar  tracking) 

*  for  docking  procedures.  The  target  platform 

*  is  a  space  station  in  circular  orbit.  * 

*  * 


#include  <stdio.h> 

#include  <math.h> 

#include  <sys/types.h> 

#include  <sys/stat.h> 

#include  <fcntl.h> 

#include  <sys/socket.h> 

#include  <netinet/in.h> 

#include  <ermo.h> 

#include  <netdb.h> 

#include  <signal.h> 

#include  <arpa/inet.h> 

^include  "sb.h" 

#define  MAXLM  4096 
#define  MAX_TIMES  500 

float  init[12],  newfunc[12],  new[12],  kl[12],  k2[12],  k3[12],  k4[12]; 

float  fcl[12][12],  frcfunc[12][6],  K[9][12],  Kinv[12][9],  M[9][6]; 

float  u_bias[9],  input[6],  volts,  frdof,  force  volts; 

float  tl,t2,t3,t4,t5,t6,x_home,x,scale,scalex; 

float  fmalout_l,collide_x, moved; 

struct  sockaddr_in  cli_addr,serv_addr; 

struct  servent  *sp; 

char  inbuf[MAXLINE],outbuf[MAXLINE]; 
int  sockfd,op_mode,flagl,scale_button,n,collision; 
int  clilen,  childpid,  newsockfd,  count; 
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void  open_spaceball(); 
void  init_spaceball(Byte  mode); 
void  write_spaceball(); 
int  read_raw_spaceball(); 
void  read_spaceball(); 
void  parse_spaceball(); 
void  close_spaceball(); 
int  read_standard  (); 
void  parse_standard  (); 
void  calculate_velocity(); 

Fn.E  *out; 

main(argc,  argv) 
int  argc; 
char  *argv[]; 

{ 

/* 

*  Declare  the  'main'  program's  variables. 

V 

SpaceballData  sd; 
char  igripbuftMAXLINE]; 
char  retumbuf[MAXLINE]; 
int  sockport; 
int  sockdsc; 

int  i,  j,  k,  1,  mm,  ctrl_num; 

int  stop_process,  test; 

float  fcn(float[],  float[],  int); 

float  pi,  facos(float),  sum; 

float  frcfix[12],  output[6][12]; 

float  init[12],  no_change,  previous_t3; 

float  u[9],  M_fix[12],  altitude; 

float  finalout_2,  finalout_3,  delta; 

float  finalout_4,  finalout_5,  finalout_6; 

float  sensitize, collide_x; 

void  r_bar(); 

void  v_bar(); 

void  motor_control(); 

void  scale_voltage(); 

printf("The  server  for  object  is  started.\n"); 

/*  Open  up  file  for  data  collection  */ 
out  =  fopen("velocity4.out","w"); 
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*  Initialize  all  the  variables  pertinent  to  this  program  to 

*  zero  (0),  to  limit  the  errors  which  might  occur  in  the 

*  computational  process. 

*/ 

for  (i  =  0;  i  <=  11;  i++) 

{ 

fmalout_l  =  0.0; 
fmalout_2  =  0.0; 
finalout_3  =  0.0; 
fmalout_4  =  0.0; 
finalout_5  =  0.0; 
finalout_6  =  0.0; 
ffcfix[i]  =  0.0; 
init[i]  =  0.0; 
new[i]  =  0.0; 
newfunc[i]  =  0.0; 

M_fix[i]  =  0.0; 

kl[i]  =  0.0; 

k2[i]  =  0.0; 

k3[i]  =  0.0; 

k4[i]  =  0.0; 

u_bias[i]  =  0.0; 

for  (j  =  0;j  <=  ll;j++) 

{ 

fcl[i]D]  =  0.0; 

} 

} 

for  (  i  =  0;  i  <=  5;  i++) 

{ 

input[i]  =  0.0; 
for(j  =  0;j<=ll;j++) 

{ 

ffcfunc[j][i]  =  0.0; 
output[i][j]  =  0.0; 

} 

} 

for  ( i  =  0;  i  <=  8;  i++  ) 

{ 

u[i]  =  0.0; 

for(j  =  0;j  <=  ll;j++) 

K[i]0]  =  0.0; 
for(j  =  0;j<=5;j++) 

M[i]0]  =  0.0; 
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} 

pi  =  acos(-l.O); 
altitude  =  0.0; 
stop_process  =  1; 
op_mode  =  P; 
volts  =  0.0; 
scale  =1.0; 
sensitize  =1.0; 
scalex  =1.0; 

/^IMPORTANT*  *  *  *IMPORTANT*  *  *  *IMPORTANT*  *  *  *IMPORTANT*  *  *  *IMPORT 

ANT* 

* 

*  Set  the  incremental  change  for  the  Runge-Kutta  computations. 

*  This  incremental  step  is  in  seconds.  It  can  be  changed  at 

*  the  discretion  of  the  user. 

*/ 

delta  =  20.0; 


/* 

*  The  following  are  the  values  for  the  appropriate  output 

*  vectors.  This  output  matrix  has  a  dimension  of  6  x  12 

*  and  it  is  similar  to  the  'Hsys'  of  R.  Lawrence's  thesis,  1992. 
*/ 


output[0][0]  = 
output[l][2]  = 
output[2][4]  = 
output  [3]  [6]  = 
output[4][8]  = 
output[5][10]  = 


1000.0; 

1000.0; 

1000.0; 

180.0/3.141592654; 

180.0/3.141592654; 

180.0/3.141592654; 


/* 

*  The  following  is  the  initialization  for  this 

*  program,  SERVER  FROBMC.C,  to  communicate  over  the 

*  network  with  OBBC_comm_hub.c 
*/ 

if  ((sockfd  =  socket(AF_INET,SOCK_STREAM,IPPROTO_TCP))  <  0) 
perror("  server;  cannot  open  stream  socket"); 
printf(" client  sck#  %d\n",  sockfd); 

serv_addr.sin_family  =  AF_INET; 
serv_addr.sin_addr.s_addr  =  INADDR_ANY; 
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serv_addr.sin_port  =  htons(4903); 

printf("%d  is  the  port\n",serv_addr.sin_port); 

if(bind(sockfd, (struct  sockaddr  *)  &serv_addr,sizeof(serv_addr))<0) 

{ 

perror("server:cannot  bind  local  address"); 
exit(O); 

} 

printf("binding  OK!  I  !\n"); 
if(listen(sockfd,  5)<0) 
perror("listen  error"); 
printf("listen()  OK!!!\n"); 


/* 

*  Check  the  port  socket,  the  one  used  for  communication  between 

*  the  FROBMC.GSL  and  this  program  to  ensure  the  link 

*  is  properly  operating.  If  the  port  socket  is  not  functioning 

*  properly,  send  a  message  to  "Standard  Error"  (stderr)  output 

*  and  exit  the  program  immediately. 

*/ 


sockport  =  atoi(argv[l]); 

if  (argc  !=  2) 

{ 

^rintf(stderr, "Usage:  %s  <port>\n",  argv[0]); 
exit(l); 

} 

if  (  net_init_socket_serv(  sockport,  &sockdsc  )  !=  0  ) 

{ 

fprintf( stderr, "Can't  initialize  server  socket.Vn"); 
printf("the  server  socket  is  initialized.\n"); 
exit(l); 

} 


/* 

*  Read  from  FROBMC.GSL.  the  following: 

*  The  initial  controller  configuration,  ctrl  num,  the  operation 

*  mode  (force  ref,  virtual  force  ref  etc.),  the  orbital 

*  altitude  of  the  space  platform. 

*  Then  create  the  initial  bias,  'stand-off  current  using 

*  stdoff_vel(altitude,  ctrl_num). 

*/ 
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stop_process  =  net_readsocket(  sockdsc,  igripbuf ); 
if  ( stop_process  ==  0  ) 

{ 

sscanf(igripbuf,"%d  %d  %f' ,  &ctrl_num,  &op_mode,  &altitude); 

printf("%s\n",  igripbuf); 

fflush(stdout); 

stdoff_vel(altitude); 

} 

/*  Initialize  target  ultimate  position  of  approach  axis.  This  is 

*  dictated  by  the  separation  distance  and  the  geometry  of  the 

*  space  station. 

*/ 

x_home  =  -90.374; 
if  (ctrl_num  ==  2) 

{ 

x_home  =  409.75; 

} 

/*  Assign  correct  tracking  method  coefficients  to  the 

*  position  controller  input,  system,  pre-filter,  and 

*  gain  matricies.  These  are  provided  by  Richard  Lawrence  (21). 

*/ 

switch(ctrl_num) 

{ 

case  2;  r_bar(); 
break; 

case  3 :  v_bar(); 
break; 

} 


/* 

*  Read  in  the  target  orbit  characteristics 
*/ 

stop_process  =  net_Teadsocket(  sockdsc,  igripbuf); 
if  (  stop_process  =  0 ) 

{ 

sscanf(igripbuf,  "%f  %f  %f  %f  %f 

%f' ,&input[0],&input[l],&input[2],&input[3],&input[4],&input[5]); 
printf("%s\n",igripbuf); 
ffiush(stdout); 

} 

/*  Make  the  necessary  transition  from  degrees  to  radians  */ 
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for  (i=3;i<=5;i++) 

input[i]  =  (input[i]*3.141592654)/180.0, 

/*  Open  a  path  to  the  spaceball  input  port  and  initialize 

*  the  spaceball  (see  spaceball  user's  guide).  Initialization  is 

*  dictated  by  the  sb.h  source  file.  Changes  must  be  coded. 

*  In  particular,  the  mode  or  the  argument  for  init  spaceball. 

*/ 

open_spaceball("/dev/ttyd2",B  19200); 
init_spaceball(SB_ST  AND  ARD); 

/*  make  initial  handshake  to  kirk  */ 

clilen  =  sizeof(cli_addr); 

newsockfd  =  accept(sockfd, (struct  sockaddr  *)  &cli_addr,&clilen); 

if((childpid=fork())<0  ) 
perror("server:  cannot  fork."); 

/*  if  handshake  is  made,  pass  the  information.  */ 
else  if(childpid  ==  0) 

{ 

printf("Communicating\n"); 

close(sockfd); 

volts=0; 

sprintf(outbuf,  "%f\n", volts); 

n=strlen(outbuf); 
put_data(newsockfd,  outbuf,  n); 

/*  printf("sent  initial  h/s.\n");  */ 

/* 

*  Continue  to  loop  until  the  whole  process  is  "killed".  That  is, 

*  the  simulation  is  killed  by  the  DENEB/IGRIP  simulation  running 

*  in  the  foreground  or  if  bad  communication  between  the  two 

*  programs  occur,  - 
*/ 

while((  1 )  &&  (stop_process  =0 )) 

{ 

/* 

*  Read  in  spaceball  controller  information  from  the  RS232  port  for 

*  the  six  values  of  the  joints,  three  translational  and 

*  three  rotational.  All  these  values  can  be  continuously  changed 
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*  These  values  must  be  converted  from  byte  values  (-127  to  128) 

*  and  the  z  values  must  be  reversed  to  match  the  simulation. 

*  NOTE:  Spaceball  x,y  and  z  values  do  not  correspond  to  the  x,y 

*  and  z  values  of  the  simulation. 

*! 

read_spaceball(«&sd); 
frdof  =  0; 

/*  Check  for  an  adjustment  (scaling)  to  the  commanded  input. 

*! 

scale_button  =  ((sd.button«24)»24); 

switch(scale_button) 

{ 

case  2:  /*  reset  scale  and  sensitivity  */ 
scale  =1.0; 
sensitize  =1.0; 
scalex=1.0; 

printf("input  back  to  normal.\n"); 
break; 

case  4:  /*  adjust  sensitivity  to  off-axes  */ 
sensitize  =  0.1; 

printf("off-axes  now  less  sensitive.\n''); 
break; 

case  5 :  /*  scale  input  by  one-half  of  off-axes  */ 
scale  =  scale  *0.5; 

printf("input  of  off  axes  halved.\n"); 
break; 

case  6:  /*  double  the  input  of  axis  of  interest  */ 
scalex=scalex*2; 
if  (scalex>4) 
scalex=4; 

printf("input  of  axis  of  interest  doubled.\n"); 
break;  - 

case  8:  /*  double  the  input  of  off  axes  */ 
scale  =  scale*2.0; 

printf("input  of  off  axes  doubled.\n"); 
break; 

default:  /*  do  nothing  */ 
break; 

} 
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/*  printf("scale  button  is  %f\n",scale_button);  */ 


/*  Now  read  in  any  spaceball  induced  changes  to  the  commanded 
*  input.  Ignore  axis  of  interest  if  flagl  conditions  met. 

*/ 

1 1  =((sd.xtrans«24)»24)/- 1 28. 0*  scale*  sensitize; 
t2=((sd .  ytrans«24)»24)/ 128.0*  scale*  sensitize; 
t3  =((sd .  ztrans«24)»24)/ - 1 28 . 0 *  scalex; 
if  (flagl>=l  &&  t3>0) 

{ 

t3-0.0; 

} 

t4=(((sd.xrot«24)»24)/128.0)*(-3.141592654/180.0)*scale*sensitize; 

t5-(((sd.yrot«24)»24)/128.0)*(3.141592654/180.0)*scale*sensitize; 

t6=^(sd.zrot«24)»24)/128.0)*(-3.141592654/180.0)*scale*sensitize; 

if  (op_mode  4) 

{ 

if(t3  >0) 
t3=l; 
if(t3  <0) 
t3=-l; 

} 

if  (op_mode  =  3  &&  t3  >  0  &&  force  volts  !=  20) 

{ 

frdof  =  t3  -  (force_volts/10.0); 
if  (previous_t3  >  t3) 
frdof =  0; 

input[0]=input[0]  +  frdof; 
previous_t3  =  t3; 

} 

else 

{ 

input[0]=t3+input[0] ; 
previous_t3  =  0; 

} 

input[  1  ]=t  1  +input[  1  ] ; 
input[2]=t2+input[2]; 
input[3  ]=t6+input[3  ] ; 
input[4]=t4+input[4] ; 
input[5]=t5+input[5]; 

/*printf("%f  %f  %f  %f  %f  %f\n",t  1  ,t2,t3,t4,t5,t6); 
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prmtf("%x  %x  %x\n",sd.xtrans,sd.ytrans,sd.ztrans);*/ 

/* 

*  Create  the  new  forcing  array  with  the  input  variables 

*  Use  the  equation: 

* 

*  init[12]  =  Gcl[12][6]  *  r[6][l]  -  Fcl[12][12]  *  x[12][l] 

* 

*  The  Gcl[12][6]  matrix  is  from  R.  Lawrence's 

*  thesis  work.  In  server  frobmc.c, 

*  the  Gcl[12][6]  matrix  assumes  the  responsibility  of  the 

*  forcing  function  for  the  equations  of  motion  and, 

*  therefore,  the  matrix  is  re-assigned  to  the  the  matrix 

*  frcfunc[12][6]. 

* 

*/ 

for  ( i  =  0;  i  <=  11;  i++) 

{ 

sum  =  0.0; 

for(j  =  0,j  <=  5;j++) 
sum  =  sum  +  frcfunc[i]0]*input0]; 
frcfix[i]  =  sum; 

} 

/* 

*  With  the  equation  to  obtain  the  vector  array  of  currents, 

*  given  as: 

* 

*  u[8]  =  M[9][6]  *  input[6][l]  -  K[9][12]  *  x[6][l] 

* 

*  From  page  4-11  and  4-12,  of  R.  Lawrence's  thesis,  the  u[9] 

*  array  contains  eight  (8)  current  variables  and  one  (1) 

*  thruster  value.  Therefore,  one  of  parts  on  the  right-hand 

*  side  of  the  above  equation, 

* 

*  M[9][6]  '*  input[6][l] 

* 

*  can  be  multiplied  now,  while  the  remaining  part 

* 

*  K[9][12]  *  x[6][l] 

* 

*  can  only  be  derived  at  the  completion  of  one  full  loop  of 

*  this  routine  because  that  is  when  the  x[6][l] 

*  values  are  obtained. 
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*/ 


for  (i  =  0;  i  <=  8;  i++) 

{ 

sum  =  0.0; 

forC  =  0;j<=5;j++) 
sum  =  sum  +  M[i]|j]*inputO]; 
M_fix[i]  =  sum; 

} 


/* 

*  Loop  which  obtains  all  Kl[i]  values. 
*! 


for  (i  =  0;  i  <=  1 1 ;  i++) 

{ 

for(j  =  0;j  <=  ll;j++) 

newOi  =  fcl[i]0]; 

kl[i]  =  fcn(new,  init,  11)  +  ffcfix[i]; 

} 


*  Loop  which  obtains  all  IC2[i]  values. 


for  (i  =  0;  i  <=  1 1 ;  i++) 

{ 

forO  =  0;j  <=  ll;j++) 

{ 

new[j]  =  fcl[i]0]; 

newfuncO]  =  init[j]  +  ((delta/2.0)  *  kl[j]); 

) 

k2[i]  =  fcn(newfunc,  new,  11)  +  ffcfix[i]; 

} 


/* 

*  Loop  which  obtains  all  K3[i]  values. 
*/ 


for  (i  =  0;  i  <=  11;  i++) 

{ 

forO  =  0;j<=ll;j++) 

{ 

new|j]  =  fcl[i]0]; 

newfunc[j]  =  initO]  +  ((delta/2.0)  *  k20]); 
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} 

k3[i]  =  fcn(newfunc,  new,  11)  +  frcfix[i]; 

} 

/* 

*  Loop  which  obtains  all  K4[i]  values. 

*/ 


for  (i  =  0;  i  <=  1 1 ;  i++) 

{ 

for  (j -0;j  <- ll;j++) 

{ 

newOl  =  fcl[i]lj]; 

newfunc[j]  =  initO]  +  delta  *  k3[j]; 

} 

k4[i]  =  fcn(newfunc,  new,  11)  +  ffcfix[i]; 

} 

*  The  following  loop  solves  each  incremental  value  for  the  the 

*  sought  after  x[6][l]  array  from  the  equation: 

* 

*  x(DOT)[12][l]  =  M_fix[12][l]  +  Fcl[12][12]  *  x(*)[12][l] 

* 

*  or,  as  will  be  shown  below: 

* 

*  xn[12][l]  =  init[12][l] 

* 

*  And  to  derive  the  desired  ouput  array,  y[6][l] 

* 

*  y[6][l]  =  output[6][12]  *  x(*)[12][l], 

*! 


for  (i  =  0;  i  <=  1 1 ;  i++) 

init[i]  =  init[i]  +  (delta/6.0)*(kl[i]  +  2.0*k2[i]  +  2.0*k3[i]  +  k4[i]); 


/* 

*  The  following  will  obtain  the  'u'  vector  array,  which 

*  consists  of  eight  current  values  and  one  thruster 

*  value.  The  bias  current,  obtained  in  the  sub- 

*  routine,  stdofF_vel(altitude,  crtl_num),  is  also  added  on  in 

*  all  9  cases.  ( 9  cases  =  8  currents  +  1  thruster ) 

* 

*  u[9][l]  =  M_fix[9][l]  -  K[9][12]  *  x(*)[12][l] 

*1 
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for  (i  =  0;  i  <=  8;  i++) 

{ 

sum  =  0.0; 

forG  =  0;j<=ll;j++) 
sum  =  sum  +  K[i][j]*initO]; 
u[i]  =  M_fix[i]  -  sum  +  u_bias[i]; 

} 


/* 

*  The  following  statements  will  find  the  appropriate 

*  output  array  to  move  the  OBJECT,  in  the  DENEB/IGRIP 

*  simulation,  accordingly.  The  below  statements  performed 

*  to  the  equation 

* 

*  y[6][l]  =  output[6][12]*x(*)[12][l] 

V 


for  (i  =  0;  i  <=  1 1 ;  i++) 

{ 

if  (  output[0][i]  !=  0.0  ) 

finalout_l  =  output[0][i]  *  init[i]; 
if(  output[l][i]  !=  0.0 ) 
finalout_2  =  output[l][i]  *  init[i]; 
if  (  output[2][i]  !=  0.0 ) 
finalout_3  =  output[2][i]  *  init[i]; 
if  (  output[3][i]  !=  0.0  ) 
finalout_4  =  output[3][i]  *  init[i]; 
if  (  output [4] [i]  !=  0.0  ) 
finalout_5  =  output[4][i]  *  init[i]; 
if  (  output[5][i]  !=  0.0  ) 
finalout_6  =  output[5][i]  *  init[i]; 

} 


/* 

*  Send  the  data  back  to  ffobmc.gsl. 

*/ 

sprintf(retumbuf,"%f  %f  %f  %f  %f  %f',  finalout_l,  finalout_2,  finalout_3, 
finalout_4,  finalout_5,  finalout_6); 

/* 

*  Check  to  make  sure  the  data  made  it  back  to  ffobmc.gsl 
*/ 
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if  (  net_writesocket(  sockdsc,  returnbuf )  !=  0  ) 

{ 

printf("Write  failed,  server  aborting... \n"); 
break; 

} 

/*  The  igripbuf  contains  environment  information  from 

*  the  frobmc.gsl  program.  This  information  must  be  read 

*  and  further  manipulated  before  being  relayed  to  the 

*  connect,  c  program  on  kirk 
*/ 


if  (net_readsocket(sockdsc,igripbuf)  !=  0) 

{ 

printf("Read  from  IGRIP  failed,  IGRIP  server  aborting.. \n"); 

net_close_socket(sockdsc); 

break; 

} 

sscanf(igripbuf,  "%f  %d",  &force_volts,&collision); 
fflush(stdout); 

printf("force  volts  =  %frn",force_volts); 

/*  Data  must  be  evaluated  to  perform  neccessary  motor  control. 

*/ 

motor_control(); 
printf("volts  =  %f\n",volts); 

/*  send  motor  control  voltage  to  OBBC  comm  hub.c  on  kirk 
*  a  handshake  from  kirk  must  be  received  first. 

*/ 

get_data(newsockfd,inbuf,MAXLINE); 

sprintf(outbuf,"%fm",volts); 

n=strlen(outbuf); 

put_data(newsockfd,outbuf,n); 

/*  calculate  velocity  */ 

calculate_velocity(finalout_l , delta); 

/*  reset  motor  voltage  */ 

volts  =  0.0; 
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} 

} 

printf("out  of  else  loop, program  terminated. \n"); 

1++; 

if  (1  ==  2)  fclose(out); 

/*net_close_socket(  sockdsc ); 
exit(  0  );*/ 

} 

^  3jfi3|C3|C5|C^^3|C3|C3|{  9f(  ^  9|C  9|(  3|C  3|C  ^  )|C  5|C  3|C  ^  9^  5|C  9|C  9|C  9|C  9jC  9|C  9|C  9^  9jC  9|(9|C9jCS^9(C9|(9|C9|C)|C9jC9|(9j(^^  ^  9|C  ^ 

* 

*  Subroutine  fcn()  which  operates  in  a  loop  and  to  obtains  a 

*  result  returns  to  each  of  the  seperate  K[i]  value  loops. 

* 

float  fcn(  NEWl,  NEW2,  T) 
float  NEW1[],NEW2[]; 
int  T; 

{ 

float  value; 
int  m; 
value  =  0; 

for  (m  =  0;  m  <=  T;  m++) 

{ 

value  =  value  +  (NEWl[m]  *  NEW2[m]); 

} 

return  value; 

} 

lifi^:i)ti)ijl)tiltilfi^^iHLilfilfiiiii/:iifHiifH!t***********************************’'f********* 

* 

*  The  following  subroutine  will  determine  the  difference  in 

*  velocities  for  two  space  vehicles.  Then  it  will  adjust  the 

*  objects  bias  current  appropriately  so  that  the  two  will  be 

*  able  to  stay  parallel- with  each  other  in  the  same  orbital 

*  plane. 

* 

*******!|e*!|e****J|t!|C******l|C*!|<****j|l******  +  ***>|e>|C**l|C***j|t***j|t**!|C!|t******y 


void  stdofF_vel(orbit) 
float  orbit; 

{ 

int  q,  r,  tolerance; 
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float  sum,  tol_check;[12],  sub_input[6],  sub_frcfix[12]; 
float  subM_fix[12],  fabs(float); 
float  subjnit[12],  sub_newfunc[12],  sub_new[12]; 
float  u_biaslast[  12],  sub_frcfunc[12],  sub_delta; 
for  (q  =  0;  q.<=  5;  q++) 
sub_input[q]  ==  0.0; 
for  (r  =  0;  r  <=  11;  r++) 

{ 

subjriit[r]  =  0.0; 
u_biaslast[r]  =  0.0; 
sub_newfunc[r]  =  0.0; 
sub_new[r]  =  0.0; 
sub_ffcfunc[r]  =  0.0; 
tol_check[r]  =  0.0; 

} 


/* 

*  Set  the  "tolerance"  flag  low  to  enable  the  R-K  rountine  to 

*  sufficiently  compute  the  values  necessary  for  the  calculation. 
*! 

tolerance  =  0; 
sub_delta  =  20.0; 

sub_input[0]  =  (orbit  -  400.0)  *  1000.0; 
if  ( abs(sub_input[0])  <  1.0 ) 

{ 

for  (q  =  0;  q  <=  8;  q++) 
u_bias[q]  =  0.0; 
tolerance  =  1; 

printf("This  is  where  subjnput  <  1 .0.\n"); 
fflush(stdout); 

} 

I* 

*  Create  the  new  forcing  array  for  the  inputted  variables 

*  Multiply  the  input  array,  the  input[i]  values,  which  is  held 

*  in  a  6  X  1  matrix,  and  pre-multiply  it  with  the 

*  ffcfunc[i]0]  values,  which  are  held  in  a  12  x  6  matrix,  to 

*  develop  a  new  12x1  matrix.  For  the  bias  current 

*  level,  this  vector  array  will  only  have  to  be  computed 

*  once  because  the  values  of 'input[q]'  are  static,  or  fixed. 

*1 


for  (q  =  0;  q<=  11;  q++) 

{ 
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sum  =  0.0; 

for  (r  =  0;  r  <=  5;  r++) 
sum  =  sum  +  ffcfunc[q][r]*subjnput[r]; 
sub_frcfix[q]  =  sum; 

} 


I* 

*  With  the  equation  to  obtain  the  vector  array  of  currents, 

*  given  as: 

* 

*  u[i]  =  M[i]0]*input|j][l]  -  K[i][k]*x[k][l] 

* 

*  Find  the  new  M[i][i]  matrix  now  and  put  the  newly  obtained 

*  values  back  into  M[i]|j].  This  vector  array  will  only  have 

*  to  be  completed  once  since  both  the  values  of  M[q][r]  and 

*  input[r]  are  static,  or  fixed. 

*/ 

for  (q  =  0;  q  <=  8;  q++) 

{ 

sum  =  0.0; 

for  (r  =  0;  r  <=  5;  r++) 
sum  =  sum  +  M[q][r]*sub_input[r]; 
subM_fix[q]  =  sum; 

} 

/* 

*  Loop  until  all  values  in  the  'u'  vector  array,  the  eight 

*  bias  currents  and  the  thruster  value  meet  the  tolerance 

*  desired  by  the  programmer. 

*/ 

while  ( tolerance  ==  0 ) 

{ 


/* 

*  Loop  which  obtains  all  Kl[q]  values. 
*/ 


for  (q  =  0;  q  <=  11;  q++) 

{ 

for  (r  =  0;  r<=  11;  r++) 
sub_new[r]  =  fcl[q][r]; 

kl[q]  =  fcn(sub_new,  sub  init,  1 1)  +  sub_ffcfix[q]; 

} 
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/* 

*  Loop  which  obtains  all  K2[q]  values. 

*/ 

for  (q  =  0;  q<=  11;  q++) 

{ 

for(r  =  0;r<=  ll;r++) 

{ 

sub_new[r]  =  fcl[q][r]; 

sub_newfunc[r]  =  sub_init[r]  +  ((sub  delta/2.0)  *  k;l[r]); 

} 

k2[q]  =  fcn(sub_newfunc,  sub_new,  11)  +  sub_frcfix[q]; 

} 


/* 

*  Loop  which  obtains  all  K3[q]  values. 
*/ 


for  (q  =  0;  q<=  11;  q++) 

{ 

for  (r  =  0;  r<=  11;  r++) 

{ 

sub_new[r]  =  fcl[q][r]; 

sub_newfunc[r]  =  sub_init[r]  +  ((sub_delta/2.0)  *  k2[r]); 

} 

k3[q]  =  fcn(sub_newfunc,  sub_new,  11)  +  sub_ffcfix[q]; 

} 

/* 

*  Loop  which  obtains  all  K4[i]  values. 

*/ 


for  (q  =  0;  q<=  11;  q-H-) 

{ 

for(r  =  0;r<=  ll;r++) 

{ 

sub_new[r]  =  fcl[q][r]; 

sub_newfunc[r]  =  sub_init[r]  +  sub_delta  *  k3[r]; 

} 

k4[q]  =  fcn(sub_newfunc,  sub_new,  11)  +  sub_frcfix[q]; 


/* 

*  Find  the  incremental  values  of  new_init  and  then  compare  them 
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*  with  the  last  values  of  new_initlast'  to  ensure  all  the 

*  values  will  meet  the  tolerance  specification. 

*/ 


for  (q  =  0;q<=  ll;q++) 

sub_init[q]  =  sub_init[q]  +  (sub_delta/6.0)*(kl[q]  +  2.0*k2[q]  +  2.0*k3[q]  + 
k4[q]); 

for  (q  =  0;  q  <=  8;  q++) 

{ 

sum  =  0.0; 

for(r  =  0;  r<=  11;  r++) 

sum  =  sum  +  K[q][r]*sub_init[r]; 
u_bias[q]  =  -1.0*(subM_fix[q]  -  sum); 
tol_check[q]  =  u_bias[q]  -  u_biaslast[q]; 
if  (tol_check[q]  <  0.0  ) 
tol_check[q]  =  -tol_check[q]; 

} 

if  ( tol_check[0]  <  0.000001  ) 

{ 

if(tol_check[l]<  0.000001  ) 

{ 

if  ( tol_check[2]  <  0.000001  ) 

{ 

if  ( tol_check[3]  <  0.000001  ) 

{ 

if  ( tol_check[4]  <  0.000001  ) 

{ 

if  ( tol_check[5]  <  0.000001  ) 

{ 

if  ( tol_check[6]  <  0.000001  ) 

{ 

if  ( tol_check[7]  <  0.000001  ) 

{ 

if  ( tol_check[8]  <  0.000001  ) 

{ 

-  for  (q  =0  ;  q  <=  5;  q++) 

{ 

tolerance  =  1; 

} 

} 

} 

} 

} 

} 
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} 


} 

} 

} 

} 

if  ( tolerance  ==  0 ) 

{ 

for  (q  =  0;q<=ll;q++) 
u_biaslast[q]  =  u_bias[q]; 


y!|t*!(C*!|c;|!j|l***!|!**:|Cj|t!(c**j|<l|l*j|t*!|<**!|<***********!|Cj|t***********>|ti|!*Ht*>|t**!|C>|tH<*** 

* 

*  Purpose:  The  purpose  if  this  subroutine  is  to  re-assign  the 

*  values  of  the  matrices  to  enable  the  usage  of  a 

*  controller  to  operate  in  the  R-bar  tracking  approach. 

>|C 


void  r_bar() 

{ 

I* 

*  The  following  are  the  coefficients  for  the  K  matrix,  the 

*  controller  gain  matrix,  for  R-Bar  tracking.  These  numbers 

*  were  generaterd  by  MATLAB  (Lawrence,Bridgman). 

*/ 


K[0][0]  =-1.9372844e+01; 
K[0][1]  =  1.1382179e+03; 
K[0][2]  =-1.0484363e+01; 
K[0][3]  =-1.2627757e+04; 
K[0][4]  =  4.8058444e-03; 
K[0][5]  =  2.6076772e-01; 
K[0][6]  =  1.9799792e+04; 
K[0][7]  =  6.5975727e+06; 
K[0][8]  = -8.04012816+03; 
K[0][9]  =-6.3170347e+05; 
K[0][10]  =  -8.9295885e+03; 
K[0][ll]  =  -2.3974952e+06; 


K[1][0]  =-1.9372920e+01; 
K[l][l]  =  1.1383228e+03; 
K[l][2]  = -1. 048463  9e+01; 
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K[l][3]  = 
K[l][4]  = 
K[l][5]  = 
K[l][6]  - 
K[l][7]  = 
K[l][8]  = 
K[l][9]  = 
K[l][10] 
K[l][ll] 

K[2][0]  = 
K[2][l]  = 
K[2][2]  = 
K[2][3]  : 
K[2][4]  : 
K[2][5] 
K[2][6] 
K[2][7] 
K[2][8] 
K[2][9] 
K[2][10] 
K[2][ll] 

K[3][0] 

K[3][l]  ^ 

K[3][2] 

K[3][3] 

K[3][4] 

K[3][5] 

K[3][6] 

K[3][7] 

K[3][8] 

K[3][9] 

K[3][10] 

K[3][ll] 

K[4][0] 

K[4][l] 

K[4][2] 

K[4][3] 

K[4][4] 

K[4][5] 

K[4][6] 

KI4][7] 

K[4][8] 


-1.2627702e+04; 

4.7943422e-03; 

2.6058334e-01; 

-1.9799731e+04; 

-6.5975459e+06; 

8.04012756+03; 

6.31703586+05; 

^  8.92956546+03; 

:  2.39748576+06; 

2.13500146+01; 
1.32900936+04; 
-1.92597086+01; 
-7.05712946+03; 
-8.36451446-02; 
-3.60788416+00; 
-1.65928176+04; 
1.62850926+05; 
5.77440036+02; 
4.69014706+04; 
=-5.61214386+04; 
=  -2.89103896+06; 

2.13499986+01; 

1.32901396+04; 

-1.92598166+01; 

-7.05711966+03; 

-8.36443016-02; 

-3.60787046+00; 

1.65920636+04; 

-1.63163096+05; 

-5.77433196+02; 

-4.69027106+04; 

=  5.61217306+04; 
=  2.89115016+06; 

-7.74906346+00; 

4.55184126+02; 

-4.19347446+00; 

-5.05115786+03; 

1.91929686-03; 

1.04249616-01; 

4.84736966+04; 

1.57426456+07; 

-3.24788186+02; 


K[4][9]  = 
K[4][10] 
K[4][ll] 

K[5][0]  = 
K[5][l]  = 
K[5][2]  ^ 
K[5][3]  = 
K[5][4]  = 
K[5][5]  = 
K[5][6]  : 
K[5][7]  : 
K[5][8]  = 
K[5][9]  ^ 
K[5][10] 
K[5][ll] 

K[6][0]  ^ 
K[6][l]  ^ 
K[6][2]  ^ 
K[6][3]  ^ 
K[6][4]  : 
K[6][5]  ^ 
K[6][6]  ^ 
K[6][7]  ^ 
K[6][8]  ^ 
K[6][9]  ^ 
K[6][10] 
K[6][ll] 

K[7][0]  ^ 

K[7][l] 

K[7][2] 

K[7][3]  ^ 

K[7][4] 

K[7][5] 

K[7][6] 

K[7][7] 

K[7][8] 

K[7][9] 

K[7][10] 

K[7][ll] 

K[8][0] 

K[8][l] 


5.8681483e+04; 
-1.7758985e+04; 
^  -5.5497698e+06; 

-7.7492422e+00; 

4.5543218e+02; 

-4.1941265e+00; 

-5.05102596+03; 

1.92077796-03; 

1.04290816-01, 

-4.84736726+04; 

-1.57426346+07; 

3.24787926+02; 

-5.86814396+04; 

^  1.77589766+04; 

^  5.54976606+06; 

1.37742466+00; 

8.57419216+02; 

-1.24254656+00; 

-4.55302526+02; 

-5.44031496-03; 

-2.33496596-01; 

3.22132376+03; 

8.81341936+05; 

5.71554336+04; 

4.75023646+06; 

=  -7.64661476+02; 
=  -3.25639356+05; 

1.37741496+00; 

8.57434506+02; 

-1.24258416+00; 

-4.55294196+02; 

-5.35255266-03; 

-2.32035976-01; 

-3.22137-236+03; 

-8.81362076+05; 

-5.71554326+04; 

-4.75023656+06; 

=  7.64680296+02; 
=  3.25646536+05; 

1.21110426-01; 

7.12576726+01; 


K[8][2]  =-9.8619627e-02; 
K[8][3]  =-3.3139152e+01; 
K[8][4]  =  3.1574096e+01; 
K[8][5]  -  1.54673 7 le+03; 
K[8][6]  = -9.548101  le-03; 
K[8][7]  =-3.2811691e+00; 
K[8][8]  = -3.71053416-02; 
K[8][9]  =  -7.74429066+00; 
K[8][10]=  2.43331636-03; 
K[8][ll]=  1.17943256+00; 


/* 

*  Th6  following  aro  tho  coofficionts  for  tho  M  matrix,  tho  pr6- 

*  filtor  matrix,  for  R-bar  tracking. 

*  Th6S6  numbors  W6r6  gonoratod  by  MATLAB  (Lawr6nc6,Bridgman) 


M[0][0]=  -1.93728446+01; 
M[0][1]=  -1.04845576+01; 
M[0][2]  =  4.79946616-03; 
M[0][3]=  2.11236056+04; 
M[0][4]  =  -8.09777166+03; 
M[0][5]  =  -7.61486446+03; 

M[1][0]=  -1.93729206+01; 
M[l][l]=  -1.04844456+01; 
M[l][2]  =  4.80072066-03; 
M[l][3]=  -2.11235446+04; 
M[l][4]  =  8.09777106+03; 
M[l][5]  =  7.61484146+03; 

M[2][0]=  1.21825716+01; 
M[2][l]=  -1.92597366+01; 
M[2][2]  =  -8.36449786-02; 
M[2][3]-  -1.66272556+04; 
M[2][4]  =  5.78939606+02; 
M[2][5]  =  -5.59305836+04; 

M[3][0]=  1.21825556+01; 
M[3][l]=  -1.92597886+01; 
M[3][2]  =  -8.36444676-02; 
M[3][3]=  1.66265016+04; 
M[3][4]  =  -5.78932766+02; 
M[3][5]  =  5.59308756+04; 
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M[4][0]  =  -7.7490634e+00; 
M[4][l]=  -4.1939361e+00; 
M[4][2]=  1.9220176e-03; 
M[4][3]=  5.1638699e+04; 
M[4][4]  =  -3.00199006+02; 
M[4][5]=  -1.46294386+04; 

M[5][0]  =  -7.74924226+00; 
M[5][l]=  -4.19366486+00; 
M[5][2]=  1.91805716-03; 
M[5][3]=  -5.16386756+04; 
M[5][4]=  3.00198746+02; 
M[5][5]=  1.46294296+04; 

M[6][0]  =  7.85976636-01; 
M[6][l]=  -1.24257336+00; 
M[6][2]  =  -5.38585446-03; 
M[6][3]=  3.40468516+03; 
M[6][4]=  5.76476116+04; 
M[6][5]  =  -5.82558946+02; 

M[7][0]  =  7.85966936-01; 
M[7][l]=  -1.24255736+00; 
M[7][2]=  -5.40701316-03; 
M[7][3]  =  -3.40473386+03; 
M[7][4]  =  -5.76476106+04; 
M[7][5]  =  5.82577766+02; 

M[8][0]=  7.14625186-02; 
M[8][l]  =  -9.86196276-02; 
M[8][2]=  3.16225916+01; 
M[8][3]=  -9.54810116-03; 
M[8][4]  =  -3.71053416-02; 
M[8][5]=  2.43331636-03; 


*  Th6  following  arc  tho  coofficionts  for  tho  closod  loop 

*  matrix  noodod  for  R-bar  tracking.  Goneratod  by  MATLAB. 
*/ 

fcl[0][l]  =  1.0; 

fcl[l][0]  =-5.10519106-06; 
fcl[l][l]  =-5.56931946-03; 
fcl[l][2]  =  8.07094276-06; 


fcl[l][3]  =  5.2205767e-03; 
fcl[l][4]  =  3.5051926e-08; 
fcl[l][5]  =  1.5119071e-06; 
fcl[l][6]  =  1.5802786e-07; 
fcl[l][7]  =  6.5408553e-05; 
fcl[l][8]  = -1.43359326-09; 


fcl[l][9]  =  2,59816516-07; 
fcl[l][10]  = -6.11170266-08; 
fcl[l][ll]  = -2.33020076-05; 


fcl[2][3]  =  1.0; 


fcl[3][0]  =-1.51262046-06; 
fcl[3][l]  =-2.17436246-03; 
fcl[3][2]  =-8.18622146-07; 
fcl[3][3]  =  -9.85963856-04; 
fcl[3][4]  =  3.74787766-10; 
fcl[3][5]  =  2.03533546-08; 
fcl[3][6]  =  2.37650606-09; 
fcl[3][7]  =  1.04491286-06; 
fcl[3][8]  =-2.51765996-11; 
fcl[3][9]  =  4.30714796-09; 
fcl[3][10]  = -9.01312316-10; 
fcl[3][ll]  = -3.69805226-07; 


fcl[4][5]  =  1,0; 


fcl[5][0]  =  2.27541806-08; 
fcl[5][l]  =  9,09268356-06; 
fcl[5]  [2]  = -5,94088606-08; 
fcl[5][3]  =  -2.48889446-05; 
fcl[5][4]  =  -8.35042136-04; 
fcl[5][5]  =  -4.08438546-02; 
fcl[5][6]  =  1.97936616-07; 
fcl[5][7]  ^  6.42059306-05; 
fcl[5][8]  =  9.80300326-07; 
fcl[5][9]  =  2.04407576-04; 
fcl[5][10]  =  -4.32978566-08; 


fcl[5][ll]  = -2,31512496-05; 


fcl[6][7]  =  1.0; 


fcl[7][0]  =  1.36787616-14; 
fcl[7][l]  =-8.26964506-11; 
fcl[7][2]  =  1.85533126-13; 
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fcl[7][3]  =-4.8641306e-12; 
fcl[7][4]  = -2.04447726-15; 
fcl[7][5]  =-3.04280916-14; 
fcl[7][6]  =-1.07529856-04; 
fcl[7][7]  =:4.33389706-03; 
fcl[7][8]  =  3.24743826-06; 
fcl[7][9]  =  2.74269536-04; 
fcl[7][10]  =  -2.99265236-04; 
fcl[7][ll]  = -1.38796726-02; 

fcl[8][9]  =  1.0; 

fcl[9][0]  =  1.83862656-15; 
fcl[9][l]  =  1.91638556-12; 
fcl[9][2]  =  1.29985726-15; 
fcl[9][3]  =  1.63945796-12; 
fcl[9][4]  =-5.31216486-14; 
fcl[9][5]  =  3.70079826-12; 
fcl[9][6]  =-2.38499976-06; 
fcl[9][7]  =-4.19560246-04; 
fcl[9][8]  =-2.92691676-04; 
fcl[9][9]  =  -2.40936336-02; 
fcl[9][10]  = -2.35155226-06; 
fcl[9][ll]  = -3.20418766-05; 

fcl[10][ll]=  1.0; 

fcl[ll][0]  =  1.38119166-13; 
fcl[ll][l]  =-1:22089626-10; 
fcl[ll][2]  =  3.76447956-13; 
fcl[ll][3]  =-8.69741146-11; 
fcl[ll][4]  =-4.19107076-15; 
fcl[ll][5]  =-6.87448646-14; 
fcl[ll][6]  =-2.48130876-04; 
fcl[ll][7]  =  5.16468156-03; 
fcl[ll][8]  =  5.68381236-06; 
fcl[ll][9]  =  4.70238916-04; 
fcl[ll][10]  = -8.66267636-04; 
fcl[ll][ll]  = -4.55824676-02; 

/* 

*  Th6  forcing  function  vector  of  the  R-bar  tracking  procedure. 
*/ 

ffcfunc[l][0]  =  5.10519106-06; 
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frcfunc[3][0]  =  1.5126204e-06; 
frcfunc[5][0]  = -2.2754180e-08; 
frcfunc[7][0]  = -1.3678761e-14; 
frcfunc[9][0]  = -1.8386266e-15; 
frcfunc[ll][P]  = -1.381 1916e-13; 

frcfunc[l][l]  = -8.0709427e-06; 
frcfunc[3][l]  =  8.1862214e-07; 
frcfunc[5][l]  -  5.9408860e-08; 
frcfunc[7][l]  = -1.8553312e-13; 
frcfunc[9][l]  = -1.2998570e-15; 
frcfunc[ll][l]  =  -3.7644795e-13; 

frcfunc[l][2]  = -3.505 1926e-08; 
frcfunc[3][2]  = -3.7478776e-10; 
frcfunc[5][2]  =  8.3504213e-04; 
frcfunc[7][2]  =  2.0444795e-15; 
frcfunc[9][2]  =  5.3121680e-14; 
frcfunc[ll][2]=  4.1910758e-15; 

frcflmc[l][3]  = -1.5802786e-07; 
frcfunc[3][3]  =  -2.3765060e-09; 
frcfunc[5][3]  = -1.9793661e-07; 
frcfunc[7][3]  =  1.0752985e-04; 
frcfuiic[9][3]  =  2.3849997e-06; 
frcfunc[ll][3]=  2.4813087e-04, 

frcfunc[l][4]  =  1.4335932e-09; 
frcfunc[3][4]  =  2.5176599e-ll; 
frcfunc[5][4]  =  -9.8030032e-07; 
frcfunc[7][4]  = -3.2474382e-06; 
frcfunc[9][4]  =  2.9269167e-04; 
frcfunc[ll][4]  =  -5.6838123e-06; 

frcfunc[l][5]  =  6.1117026e-08; 
frcfunc[3][5]  =  9.013 123  le-10; 
frcfunc[5][5]  =  4.^297856e-08; 
frcfunc[7][5]  =  2.9926523e-04; 
frcfunc[9][5]  =  2.3515522e-06; 
frcfunc[ll][5]=  8. 6626763 e-04; 

} 


^***!(c**!|e!|t**Ht****J|<****>l<>l<!|<***************!|'********J|!**!|!!|<*****!|<***!|<*** 
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*  Purpose:  The  purpose  if  this  subroutine  is  to  re-assign  the 

*  values  of  the  matrices  to  enable  the  graphics 

*  simulation  to  depict  V-bar  tracking  maneuevers. 

void  v_bar() 

{ 

/* 

*  The  following  are  the  coefficients  for  the  K  matrix  (contains 

*  the  controller  gain  coefficients),  needed  by  V-Bar  tracking. 
*/ 


K[0][0]  =  -3.6612135e+01; 
K[0][1]  =  -1.39048026+04; 
K[0][2]  =  5.13255876+00; 
K[0][3]  =  -1.0949306e+04; 
K[0][4]  =  8.3798158e-03; 
K[0][5]  =  5.9216850e-01; 
K[0][6]  =  2.6305463e+01; 
K[0][7]  =  5.91993346+03; 
K[0][8]  =  -1.8968539e+03; 
K[0][9]  =  -1.6171560e+04; 
K[0][10]=  - 1.801 923  8e+04; 
K[0][11]=  -1.6660839e+06; 

K[1][0]  =  -3.6612122e+01; 
K[l][l]  -  -1.3904757e+04; 
K[l][2]  =  5.1326473e+00; 
K[l][3]  =  -1.0949301e+04; 
K[l][4]  =  8.3862481e-03; 
K[l][5]  =  5.9261237e-01; 
K[l][6]  =  -2.6300618e+01; 
K[l][7]  =  -5.9197905e+03; 
K[l][8]  =  1.89681 17e+03; 
K[l][9]  =  1.6322903e+04; 
K[l][10]=  1.80192446+04; 
K[l][ll]=  1. 666067  le+06; 

K[2][0]  =  1.3096827e+01; 
K[2][l]  =  6.1718000e+03; 
K[2][2]  =  -4.50543236+00; 
K[2][3]  =  2.2426954e+03; 
K[2][4]  =  -4.2521850e-03; 
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K[2][5]  = 
K[2][6]  = 
K[2][7]  = 
K[2][8]  = 
K[2][9]  = 
K[2][10]  = 
K[2][ll]  = 

K[3][0]  - 
K[3][l]  = 
K[3][2]  = 
K[3][3]  = 
K[3][4]  = 
K[3][5]  = 
K[3][6]  = 
K[3][7]  = 
K[3][8]  = 
K[3][9]  = 
K[3][10]  = 
K[3][ll]  = 

K[4][0]  = 
K[4][l]  = 
K[4][2]  = 
K[4][3]  = 
K[4][4]  = 
K[4][5]  = 
K[4][6]  = 
K[4][7]  = 
K[4][8]  = 
K[4][9]  = 
K[4][10]  = 
K[4][ll]  = 

K[5][0]  = 
K[5][l]  = 
K[5][2]  = 
K[5][3]  == 
K[5][4]  = 
K[5][5]  = 
K[5][6]  = 
K[5][7]  = 
K[5][8]  = 
K[5][9]  = 
K[5][10]  = 


-3.41249746-01; 

-7.21127696+03; 

-6.02295246+05; 

9.63848326+02; 

8.49228986+05; 

-5.20404716+02; 

-1.33825726+05; 

1.30968726+01; 

6.17183306+03; 

-4.50541386+00; 

2.24270736+03; 

-4.17206556-03; 

-3.37948676-01; 

7.21127536+03; 

6.02295206+05; 

-9.64024566+02; 

-8.49290486+05; 

5.20425196+02; 

1.33832706+05; 

-2.36207676+00; 

-8.97086906+02; 

3,31128766-01; 

-7.06409216+02; 

5.24761466-04; 

3.75884276-02; 

1,69794596+04; 

1,41483676+06; 

6.99260586+01; 

4.15366036+05; 

-1.61195636+02; 

-5.20965816+04; 

-2.36206896+00; 

-8.97078196+02; 

3.31142606-01; 

-7.06404156+02; 

5.56920086-04; 

3.88490496-02; 

-1.69794596+04; 

-1.41483676+06; 

-6.99287816+01; 

-4.15356276+05; 

1.61196026+02; 


K[5][ll]=  5.2095498e+04; 


K[6][0]  =  5.2385689e+00; 
K[6][l]  =  2.4685985e+03; 
K[6][2]  =  4.80224906+00; 
K[6][3]  =  8.97030036+02; 
K[6][4]  =  -2.02298526-03; 
K[6][5]  =  -1.49655546-01; 
K[6][6]  =  2.24022446+02; 
K[6][7]  =  7.81755116+03; 
K[6][8]  =  7.53090346+03; 
K[6][9]  =  7.41363236+06; 
K[6][10]=  -8.69348316+02; 


K[6][ll]=  -8.13728336+05; 


K[7][0]  -  5.23891086+00; 
K[7][l]  =  2.46885476+03; 
K[7][2]  =  -1.80208946+00; 
K[7][3]  =  8.97131056+02; 
K[7][4]  -  -1.34671506-03; 
K[7][5]  =  -1.22023826-01; 
K[7][6]  =  -2.24023106+02; 
K[7][7]  =  -7.81756666+03; 
K[7][8]  =  -7.53097396+03; 
K[7][9]  =  -7.41365696+06; 
K[7][10]=  8.69356516+02; 
K[7][ll]=  8.13731126+05; 


K[8][0]  =  7.57637696-02; 
K[8][l]  =  2.98385196+01; 
K[8][2]  =  -1.30437476-02; 
K[8][3]  =  2.12400336+01; 
K[8][4]  =  9.95161376+00; 
K[8][5]  =  8.68236296+02; 
K[8][6]  =  -7.95390946-02; 
K[8][7]  =  -2.31936696+00; 
K[8][8]  =  -1.30965496+00; 
K[8][9]  =  -2.70114206+03; 
K[8][10]=  1.74835816-01; 


K[8][ll]=  2.97497256+02; 


/* 

*  Th6  following  coofficionts  ar6  for  tho  M  matrix,  tho  pro- 

*  filtor  matrix.  Th6S6  valu6s  W6r6  gonoratod  by  MATLAB. 

*  V-Bar  tracking. 
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M[0][0]  = 
M[0][1]  = 
M[0][2]  = 
M[0][3]  = 
M[0][4]  = 
M[0][5]  = 

M[1][0]  = 
M[l][l]  = 
M[l][2]  = 
M[l][3]  - 
M[l][4]  = 
M[l][5]  = 

M[2][0]  = 

M[2][l] 

M[2][2] 

M[2][3] 

M[2][4] 

M[2][5] 

M[3][0] 

M[3][l] 

M[3][2] 

M[3][3] 

M[3][4] 

M[3][5] 

M[4][0] 

M[4][l] 

M[4][2] 

M[4][3] 

M[4][4] 

M[4][5] 

M[5][0] 

M[5][l] 

M[5][2] 

M[5][3] 

M[5][4] 

M[5][5] 

M[6][0] 


-3.6612135e+01; 

5.1326009e+00; 

.8.37370026-03; 

2.59097296+01; 

-1.95212266+03; 

-1.83048486+04; 

-3.66121226+01; 

5.13260526+00; 

8.39236376-03; 

-2.59048846+01; 

1.95208046+03; 

1.83048546+04; 

-3.61055266+01; 

-4.50540506+00; 

-4.01710146-03; 

-7.19606496+03; 

3.08837716+03; 

-7.04894046+02; 

-3.61054816+01; 

-4.50544106+00; 

-4.40714916-03; 

7.19606326+03; 

-3.08855336+03; 

7.04914526+02; 

-2.36207676+00; 

3.31140376-01; 

6.25041926-04; 

1.69430906+04; 

9.76194026+02; 

-2.39893926+02; 

-2.36206896+00; 

3.31130996-01; 

4.56639616-04; 

-1.69430906+04; 

-9.76196756+02; 

2.39894316+02; 

-1.44423726+01; 


M[6][l]=  -1.8020246e+00; 
M[6][2]=  -1.5768961e-05; 
M[6][2]  =  2.21915436+02; 
M[6][3]  =  2.56707866+04; 
M[6][4]=  -2.39003136+03; 

M[7][0]=  -1.44420306+01; 
M[7][l]=  -1.80231386+00; 
M[7][2]=  -3.35393126-03; 
M[7][3]  =  -2.21916086+02; 
M[7][4]  -  -2.56708566+04; 
M[7][5]  =  2.39003946+03; 

M[8][0]=  2.61158676-02; 
M[8][l]=  -1.30437476-02; 
M[8][2]=  1.00001096+01; 
M[8][3]  =  -7.95390946-02; 
M[8][4]=  -1.30965496+00; 
M[8][5]=  1.74835816-01; 


/* 

*  Th6  following  ar6  th6  coofficionts  for  tho  closod  loop  matrix 

*  g6n6rat6d  by  MATLAB  (Lawronco, Bridgman)  for  V-Bar  tracking. 
*! 


fcl[0][l]  =  1.0; 


fcl[l][0]  =  2.81909126-06; 
fcl[l][l]  --4.81890896-04; 
fcl[l][2]  =  3.51780126-07; 
fcl[l][3]  =  2.08812926-03; 
fcl[l][4]  =  3.28879646-10; 
fcl[l][5]  =  2.65156576-08; 
fcl[l][6]  =  6.41256796-11; 
fcl[l][7]  =  1.51554396-09; 
fcl[l][8]  =  6.88019326-09; 
fcl[l][9]  =  2.40081976-06; 


fcl[l][10]  = -7.99435516-10; 
fcl[l][ll]  = -2.72687036-07; 


fcl[2][3]  =  1.0; 


fcl[3][0]  =-1.53425776-05; 
fcl[3][l]  =-8.09013616-03; 
fcl[3][2]  =  2.15085446-06; 
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fcl[3][3]  =  -4.5883849e-03; 
fcl[3][4]  =  3.5129702e-09; 
fcl[3][5]  =  2.48245506-07; 
fcl[3][6]  =  1.01512316-09; 
fcl[3][7]  =  ,2.99576446-08; 
fcl[3][8]  =-8.84194946-09; 
fcl[3][9]  =  3.17106726-05; 
fcl[3][10]=  1.27075926-09; 


fcl[3][ll]  = -3.51523926-06; 


fcl[4][5]  =  1.0; 


fcl[5][0]  =  4.84224086-08; 
fcl[5][l]  =  2.21972066-05; 
fcl[5][2]  =-1.39452756-08; 
fcl[5][3]  =  7.32037726-06; 
fcl[5][4]  =  -2.64064636-04; 
fcl[5][5]  =  -2.29267946-02; 
fcl[5][6]  =  2.10018506-06; 
fcl[5][7]  =  6.12416586-05; 
fcl[5][8]  =  3.45815466-05; 


fcl[5][9]  =  7.13223646-02; 
fcl[5][10]  = -4.61660456-06; 
fcl[5][ll]  = -7.85526736-03; 


fcl[6][7]  =  1.0; 


fcl[7][0]  =-8.00468546-14; 
fcl[7][l]  =-3.83903326-11; 
fcl[7][2]  =  4.26803186-14; 
fcl[7][3]  =-3.42257926-13; 
fcl[7][4]  =-1.44833906-14; 
fcl[7][5]  =-1.05868286-12; 
fcl[7][6]  =  -2.87227826-04; 
fcl[7][7]  =-2.39935136-02; 
fcl[7][8]  =  4.89788336-06; 
fcl[7][9]  =  9.13235946-04; 
fcl[7][10]  =  -8.72609066-07; 


fcl[7][ll]  = -7.16460266-05; 


fcl[8][9]  =  1.0; 


fcl[9][0]  =  3.73178386-14; 
fcl[9][l]  =  2.01598326-12; 
fcl[9][2]  =-4.21316776-14; 
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fcl[9][3]  =  1.0032060e-ll; 
fcl[9][4]  =-4.6428223e-13; 
fcl[9][5]  =  3.4128175e-12; 
fcl[9][6]  =  -2.2684248e-08; 
fcl[9][7]  =-:2.5126452e-05; 
fcl[9][8]  -  -9.7419189e-06; 
fcl[9][9]  =  -2.02598016-03; 
fcl[9]  [10]  = -2.56810766-05; 
fcl[9][ll]  = -2.17639986-03; 


fcl[10][ll]=  1.0; 


fcl[ll][0]  = 
fcl[ll][l]  = 
fcl[ll][2]  = 
fcl[ll][3]  = 
fd[ll][4]  = 
fcl[ll][5]  = 
fcl[ll][6]  = 
fcl[ll][7]  = 
fcl[ll][8]  = 
fcl[ll][9]  = 
fcl[ll][10] 
fcl[ll][ll] 


-8.82958966-14; 

-5.19847226-11; 

-2.19241746-14; 

-3.49374626-11; 

-5.57747126-14; 

-3.46929506-12; 

-2.11263366-06; 

-1.27686356-04; 

-2.45161406-05; 

7.65691216-05; 

=  -2.39995906-04; 
=  -2.18677466-02; 


/* 

*  Th6  forcing  function  vector  for  the  V-bar  tracking  procedure. 
*/ 


ffcfunc[l][0]  =-2.81909126-06; 
ffcfunc[3][0]  =  1.53425776-05; 
ffcfunc[5][0]  =  -4.84224086-08; 
ffcfunc[7][0]  =  8.00468546-14; 
ffcfunc[9][0]  =-3.73178386-14; 
ffcfunc[ll][0]=  8.82958966-14; 


ffcfunc[l][l]  =-3.51780126-07 
ffcfunc[3][l]  =-2.15085446-06 
frcfunc[5][l]  =  1.3945275e-08; 
ffcfunc[7][l]  =-4.26803186-14 
ffcfunc[9][l]  =  4.21316776-14; 
frcfunc[l  !][!]=  2.19241756-14; 


ffcfunc[l][2]  =-3.28879646-10; 
frcfunc[3][2]  = -3.5129702e-09; 
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frcfunc[5][2]  = 
frcfiinc[7][2]  = 
frcfunc[9][2]  = 
frcfunc[ll][2]  = 

frcfunc[l][3]  =■ 
frcfunc[3][3]  =  • 
frcfunc[5][3]  =  ■ 
frcfunc[7][3]  = 
frcfunc[9][3]  = 
frcfunc[ll][3]  = 

frcfunc[l][4]  =  ■ 
frcfunc[3][4]  = 
frcfiinc[5][4]  =  ■ 
frcfunc[7][4]  =  • 
frcfunc[9][4]  = 
frcfunc[ll][4]  = 

frcfunc[l][5]  = 
frcfunc[3][5]  =• 
frcfunc[5][5]  = 
frcfunc[7][5]  = 
frcfunc[9][5]  = 
frcfunc[ll][5]  = 


2.6406463e-04; 

1.4483415e-14; 

4.6428224e-13; 

^  5.5774730e-14; 

-6.4125680e-ll; 

-1.01512316-09; 

-2.10018506-06; 

2.87227826-04; 

2.26842486-08; 

^  2.11263366-06; 

-6.88019326-09; 

8.84194946-09; 

-3.45815466-05; 

-4.89788336-06; 

9.74191896-06; 

=  2.45161406-05; 

7.99435516-10; 

-1.27075926-09; 

4.6166045e-06; 

8.72609066-07; 

2.56810766-05; 

=  2.39995906-04; 


} 


^*******JKj|Cj|C****!|<****!K*=l<*********=l‘*******>l'**>l'********=t‘******>l'** 

*  This  subroutin6  p6rforms  all  r6maining  analysis  for  * 

*  motion  of  tho  actuator  on  th6  manual  controllor.  * 

void  motor_control() 

{ 

/*  motor  mov6  */  - 

collid6_x  =  xhorno; 

switch(op_mod6) 

{ 

cas6  1 :  /*  simpl6  mod6  */ 
volts=0; 
broak; 

cas6  2:  /*  forc6  rofloction  modo  */ 
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case  3 :  /*  virtual  force  reflection  mode  */ 
if  (collision  ==  1) 

{ 

flagl++; 

.  if(flagl  ==  1) 

collide_x  =  finalout_l/1000.0; 

} 

else  flagl=0; 

volts  =  (t3/scalex)*10.0+force_volts; 

if  (input[0]  >  collide  x) 
input[0]  =  collidex; 
if  (volts  >=  0) 
volts  =  0.015; 
scale_voltage(); 
if(t3<=0) 
volts=0; 
break; 

case  4:  /*  electronic  funneling  mode  */ 
if  (force_volts  =  0  &«&  t3  >=  0) 

{ 

flagl=l; 

input[0]=finalout_l  / 1 000. 0; 

} 

else 

flagl=0; 

if(t3>0) 

{- 

volts=0.025  *force_volts; 
break; 

} 

if(t3<0) 

{ 

volts=-0.035; 

break; 

}  ' 
else  volts=0; 

} 

} 


*  This  subroutine  scales  the  voltages  to  necessary  values  for  input  to  the  servo  amplifier. 

j|!!|(**j(c*!((*:(t:(t!|t:(c**********j(:**j|tj|t**j(:******>|e**!|t*#*#:(i*******:(<***  +  j|c!(c!(t*j|!*****^ 
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void  scaIe_voltage() 

{ 

if  (volts  >  0) 

volts=volts* 0 . 0050+0 .025; 
if  (volts  <  0) 

volts=volts*0.0055-0.035; 

} 


*  This  subroutine  calculates  closure  rate  during  simulation. 

* 

*!|tj|t!|<H«*********=l<!('*************************>t!*>|e**!|t****>|e***lt!*Ji!**>l<***!|<*/ 

void  calculate_velocity(displaced, timer) 
float  displaced, timer; 

{ 

float  velocity, elapsed; 

printf("in  the  velocity  routine.\n"); 
count++; 
if  (count  ==  1) 
moved  =  finalout_l; 
if  (count  ==  3) 

{ 

velocity  =  ((displaced-moved)/(timer*3))/1000.0; 
fprintf(out,  "%fm",velocity); 
printf("the  velocity  is;  %f\n", velocity); 
count=0; 

} 

} 
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Appendix  C 


C.  1  Graphics  Simulation  Software:  Flowchart 


Figure  C-1  Frobmc.gsl  Flow  Chart 
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C.2  Graphical  Simulation  Software:  Source  Code  Listing 


—  Paul  Woznick,  Jul  94 

—  Adapted  from  program  asset,  T.  Bridgman. 

—  frobmc.gsl  must  begin  with  the  'PROGRAM'  name  followed 

—  by  the  name  of  the  device  being  programmed  in  a  WORKCELL. 

—  The  device  OBJECT  will  be  assigned  to  this  program. 

—  A  separate  server/number  crunching  program  must  be 

—  running  before  the  simulation  starts.  To  enable  the  'C 

—  routine,  goto  the  /usr/deneb/igrip.4d/giftware  directory  and 

—  type  server_ffobmc  2074.  With  this,  the  two 

—  can  communicate  with  each  other  through  the  address  location 

—  2074.  Ensure  OBBC_comm_hub.c  is  all  ready  running  on  KIRK. 


Program  object 


-  Declaration  of  the  variables  that  will  be  used  in  this  program. 

-  'VAR'  variables  are  ones  declared  frobmc.gsl  while 

-  the  'CLI_VAR'  variables  are  used  when  a  command  like 

-  CLI("  ")  is  called. 


VAR 


pick,  track_num,  i:  INTEGER 
view  num:  INTEGER 


preference: 

opmode: 

loop: 

collchecker: 

flagger: 

X,  Y: 
orbit: 
extjt: 

volts,virt_dist: 


INTEGER 

INTEGER 

INTEGER 

INTEGER 

INTEGER 

REAL 

REAL 

REAL 

REAL 


force_ref_axis_dist:  REAL 
xf,xo,yf,yo,zf,zo:  REAL 
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yawf,yawo,rollf:  REAL 
rollo,pitchf,pitcho:  REAL 
z_check,y_check:  REAL 


yaw_check: 

funnel_radius: 

pitchcheck: 

rollcheck: 

collidex; 

jt_in: 

jt_out: 

pl,p2: 


REAL 

REAL 

REAL 

REAL 

REAL 

ARRAY[6]  of  REAL 
ARRAY[6]  of  REAL 
POSITION 


CLI  VAR 


stand_oflf;  REAL 
tempsep:  REAL 

Begin 


-  Below,  the  user  will  be  promted  for  the  type  of  control 

-  employed  to  dock  the  OBJECT  with  a  space  station. 


write("Before  the  simulation  begins,  choose  from  the  ",  cr) 
write("the  tracking  options  listed  below.",  cr) 
write(cr) 

DELAY  1000 

write("The  choices  are:",  cr) 
write(cr) 

write("  1.  V-BAR  tracking.",  cr) 
write("  2.  R-BAR tracking.",  cr) 
write(cr) 

read_kbd(  'Enter  a  tracking  preference',  preference ) 
write(cr) 

write("You  must  also  choose  the  mode  of  operation  of",  cr) 

write("the  controller.  The  choices  are:",  cr) 

write(cr) 

write("  1.  Simple  6DOF  control.",  cr) 
write("  2.  6  DOF  control  with  force  reflection.",  cr) 
write("  3.  6  DOF  control  with  virtual  force  reflection.",  cr) 
write("  4.  6  DOF  control  with  Electronic  fiinneling.",  cr) 
read_kbd(  'Enter  operation  mode',  opmode  ) 
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write(cls) 

if  (opmode  >  4)  then 
opmode  =  1 
endif 


—  Open  up  a  port  for  communication  with  server_ffobmc.c. 

—  For  this  simulation,  the  communications  port 

—  is  assigned  unit  number  3 .  Therefore,  all  writing 

—  to  and  reading  from  server  frobmc.c  necessary  for  this 
~  simulation  is  done  through  unit  #3. 


open  client  'hardy;2074'  for  update  as  3 


“  Set  up  the  space  station  view  and  allocate  appropriate 
-  V-bar  or  R-bar  tracking  matricies. 


view_station() 


—  Initialize  docking  position  to  match  camera  view  at 

—  separation  of  500m. 


SWITCH  preference 

CASEl;  xf^-90374 
y^5 12640' 
zf=-4406 

collidex  =  xf 

CASE  2:  x^409700 

3^12873 
zf=-5039 

collide_x  =  xf 

ENDSWITCH 
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yawf=0 

pitchf=0 

rollf=0 


—  After  either  V-Bar  tracking  or  R-Bar  tracking  is  picked  have 

—  the  command  of  the  program  goto  the  'position()'  sub-routine 

—  to  prompt  the  user  to  input  the  six  (6)  needed  values  for 

—  "automated"  flight.  The  six  (6)  values  are  three  (3)  trans- 
“  lational  and  three  (3)  rotational.  Recommended  values  are: 

—  x=400,  y=  12,  z=  -5,  xrot=yrot=zrot=0. 


rendevous_position() 


-  Write  to  server_frobmc.c  the  pertinent  values  user  preference 

-  and  simulation  execution.  The  values  sent  to 

-  server_frobmc.c  are  the  tracking  preference,  the  operation 
“  mode  (ie.  virtual  force  reflection)  and  station  altitude. 

-  Then  send  the  object  orbital  characteristics  after  rendevous. 


write  #3,  ( track_num,' ',  opmode,' temp  sep,  cr ) 

DELAY  10 

write  #3,  ( jt_out[0],' ',  jt_out[l], ' jt_out[2], ' jt_out[3], ' ',  jt_out[4], ' ',  Jt_out[5], 


—  Turn  on  collision  queue  if  in  a  force  reflection  mode. 


if  (opmode  >1)  then 
ADD  'freedom', 'asset'  TO  QUEUE 
SET  COLLISION  CHECKS  ON 
endif 
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—  Initialize  zero  force  f/b  if  in  simple  DOF  mode. 


if  (opmode  ===1)  then 
volts  =  0.0 
collchecker  =  0 
endif 


—  This  simulation  will  keep  operating  until  the  user  presses 

—  both  the  middle  and  the  right  mouse  buttons  simultaneously. 


while  (pick  <>  3)  do 
pick  =  MOUSE_BUTTON(  X,  Y  ) 


-  Read  from  the  sub-routine  the  up-dated  values  so  the 

-  object  can  move  accordingly.  The  values  read  in  are 

-  the  three  (3)  translational  movements,  jt_in[0]  thru 

-  jt_in[2]  and  the  three  (3)  rotational  movements,  jt_in[3] 
“  thru  jt_in[5]. 


read  ( #3,  jt_in[0],  jt_in[l],  jt_in[2],  jt_in[3],  jt_in[4],  jt_in[5] ) 


-  Use  the  MOVE  JOINT  _  TO  'value'  IMMEDIATE  command  to 

—  move  each  of  the  six  (6)  joints  of  the  object. 


if  (coll  checker  =  1  OR  jt_in[0]  >  collide  x)  then 

jt_in[0]  =  collide_x 

endif 

MOVE  JOINT  1  TO  jt_in[0]  IMMEDIATE 
MOVE  JOINT  2  TO  jt_in[l]  IMMEDIATE 
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MOVE  JOINT  3  TO  jt_in[2]  IMMEDIATE 
MOVE  JOINT  4  TO  jt_in[3]  IMMEDIATE 
MOVE  JOINT  5  TO  jt_in[4]  IMMEDIATE 
MOVE  JOINT  6  TO  jt_in[5]  IMMEDIATE 
SIM_UPDATE 


—  Determine  the  voltage  necessary  to  provide  the  appropriate 

—  force  reflection  to  the  manual  controller.  Send 

—  this  information  to  server  ffobmc.c 


if  (opmode  >1)  then 
check_position() 
collide_checker() 
calculate_force2volts() 
endif 

—  write(volts,'  ',coll_checker,  cr) 
write  #3,  ( volts,'  ',coll_checker,  cr ) 


~  The  program  is  terminated  when  the  value  'pick'  =  3. 


endwhile 


—  Close  the  port  address  so  this 
~  address  doesn't  'hang'  or  go  into  a  'dead-lock'. 


close  #3 


—  Set  the  'MULTI  VIEWS'  from  the  two  (2)  screen,  horizontally 

—  split  window  to  the  full,  unsplit  picture  window.  Also 

—  set  the  view  to  a  good  spectator  view  by  using  the 

—  selected  view,  'spec_canada.' 
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CLIC'MULTI  VIEWS  0") 

CLIC'SET  VIEW  TO  'spec_canada"') 


—  End  the  main  program  with  the  END'  command  following  by 

—  name  of  the  main  program,  in  this  case  'object'. 


END  object 


“  All  the  procedures  start  here. 


—  The  following  sub-routine  is  for  tracking  with  a  space  station 


Procedure  view_station() 
Begin 


—  Set  view_num  to  T  for  viewing  space  station. 

—  and  track  num  to  '2'  for  R-Bar  controller  configuration 

—  or  track_num  to  3  for  V-bar  tracking 


view  num  =  1 
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—  Prompt  the  user  for  the  separation  between  the  space 

—  station  and  the  object.  This  depends  on  tracking 

—  configuration. 


if  (preference  ==  2)  then 
track_num  =  2 
write(  els ) 

write("You  have  selected  R-BAR  tracking.  ",  cr) 
write("At  the  prompt  below,",  cr) 
write("indicate  the  separation  between  the  ",  cr) 
write("space  station  and  the  object  (in  meters).",  cr) 
DELAY  5000 

write("Remember  that  R-bar  tracking  dictates  an ",  cr) 
write("approach  to  the  target  along  the  target's  ",  cr) 
write("position  vector,  r.  A  recommended  ",  cr) 
write("safe  minimum  separation  is  100  ",  cr) 
write("meters,  therefore  acceptable  values  ",  cr) 
write("of  separation  should  be  greater  than ",  cr) 
write("100  meters",  cr) 

read_kbd(  'Enter  the  separation,  in  meters',  stand_ofif ) 

temp_sep  =  400000  +  stand_off 

temp_sep  =  temp_sep/1000 

DELAY  500 

write(  els ) 

ext  Jt  =  0 

endif 

if  (preference  ==  1)  then 
track_num  =  3 
write(  els ) 

write("You  have  selected  V-BAR  tracking.  ",  cr) 
write("At  the  prompt  below,",  cr) 
write("indicate  the  separation  between  the  ",  cr) 
write("space  station  and  the  object  (in  meters).",  cr) 
DELAY  5000 

writeC'Remember  that  V-bar  tracking  dictates  an  ",  cr) 
write("approach  to  the  target  along  the  target's  ",  cr) 
write("orbit  (east/west).  A  recommended  ",  cr) 
write("safe  minimum  separation  is  100  ",  cr) 
write("meters,  therefore  acceptable  values  ",  cr) 
write("of  separation  should  be  greater  than ",  cr) 
write("100  meters",  cr) 

read_kbd(  'Enter  the  separation,  in  meters',  stand_off ) 
temp_sep  =  400 


89 


DELAY  500 
write(  els ) 
extjt  =  90 
endif 


-  convert  standoff  distance  to  milimeters 


stand_off=  stand_oflf  *  1000 
DELAY  500 


—  Retrieve  the  space  station  from  the  /usr/deneb/Usrlib/DEVICES 
~  directory  and  translate  it  to  the  standoff  distance  specified 

—  by  the  user. 


if  (track_num  ==  2)  then 

CLIC'GET  DEVICE  Vusr/deneb/Usrlib/DEVICES/freedom"') 
DELAY  100 

CLI(" ACTIVATE  'freedom'") 

CLIf  TRANSLATE  DEVICE  freedom  TO  stand_off,  0,  0") 
DELAY  500 

CLIC'DEACTIVATE  'freedom'") 

DELAY  500 
endif 

if  (track  num  =  3)  then 

CLIC'GET  DEVICE  '/usr/deneb/Usrlib/DEVICES/freedom'") 
DELAY  100 

CLI(" ACTIVATE  'freedom'") 

CLI("TRANSLATE  DEVICE  freedom  TO  0,  stand_off,  0") 
DELAY  500 

CLIC'ROTATE  DEVICE  freedom  TO  0,  0,  90") 

DELAY  100 

CLIC'DEACTIVATE  'freedom'") 

DELAY  500 
endif 


—  Move  the  object  to  position  (0,  0,  0,  0,  0,  0)  so  that 
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—  the  simulation  can  begin  from  the  original  reference  point. 


MOVE  JOINT  1  TO  jt_in[0]  IMMEDIATE 
MOVE  JOINT  2  TO  jt_in[l]  IMMEDIATE 
MOVE  JOINT  3  TO  jt_in[2]  IMMEDIATE 
MOVE  JOINT  4  TO  jt_in[3]  IMMEDIATE 
MOVE  JOINT  5  TO  jt_in[4]  IMMEDIATE 
MOVE  JOINT  6  TO  jt_in[5]  IMMEDIATE 
DELAY  500 


—  Set  split  screen  views  to  the  space  station  viewing. 


CLIC'MULTI  VIEWS  6") 

CLI(" ACTIVATE  VIEW  1") 
CLIC'SET  VIEW  TO  'ssf_canada"') 
if  (track_num  ==  3)  then 
CLIC'SET  VIEW  TO  'vbar_object'") 
endif 

CLI(" SCALE  WORLD  TO  20000") 
CLIf  ACTIVATE  VIEW  2") 

CLIf  ATTACH  EYE  TO  TAG  pi ") 
CLI(" SCALE  WORLD  TO  20000") 
End 


“  This  subroutine  prompts  for  the  initial  desired  position 
—  command. 


Procedure  rendevous_position() 

Begin 

write("The  following  prompts  below  will  ask  ",  cr) 
write("for  a  series  of  attributes  about ",  cr) 
write("the  rendevous  orbit.  Requested  are ",  cr) 
write("three  position  and  three  attitude  values.",  cr) 
read_kbd(  'Enter  an  attainable  x  (m)',  jt_out[0]  ) 
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read_kbd(  'Enter  an  attainable  y  (m)',  jt_out[l]  ) 
read_kbd(  'Enter  an  attainable  z  (m)',  jt_out[2]  ) 
read_kbd(  'Enter  an  attainable  x  rot  (deg)',  jt_out[3] ) 
read_kbd(  'Enter  an  attainable  y_rot  (deg)',  jt_out[4] ) 
read_kbd(  'Enter  an  attainable  z_rot  (deg)',  jt_out[5] ) 
write(  els ) 

End 


—  This  procedure  makes  joint  values  from  the  simulation 
~  available  for  manipulation  by  program  procedures. 

Procedure  check_position() 

Begin 

lJNPOS('asset',xo,yo,zo,yawo,pitcho,rollo) 

End 


—  This  procedure  initiates  the  creation  of  the  forces 

—  of  the  object/environment  interaction 


Procedure  calculate_force2volts() 

Begin 

force_ref_axis_dist  =  xf-xo 
SWITCH  opmode 

CASE  2:  volts=0 

if(force_ref_axis_dist  <=  0)then 
volts  =  force_ref_axis_dist/ 1000.0 
if  (volts  <  -10)  then 
volts  =  -10 
endif 
return 
endif 
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CASE  3 :  virtual_force2volts() 
return 

CASE  4:  fumel_force2volts() 
return 

ENDSWITCH 

End 


-  This  procedure  creates  the  virtual  spring  environment 

—  and  the  associated  forces  involved  with  it's  interaction. 


Procedure  virtual_force2volts() 

Begin 

virt_dist  =  (100000.0  -  force_ref_axis_dist)/ 1000.0 
if  (virt_dist  <=  0)  then 
return 
endif 

volts  =  (virt_dist^2)/1000 

if  (volts  >  10.0)  then 
volts  =10.0 
endif 

volts=-volts 

End 


-  This  procedure  checks  for  a  collision  between  the  space 

—  station  and  the  tracking  vehicle. 


Procedure  collide_checker() 
Begin 
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coll_checker  =  DEV_COLLISIONS('freedom','asset') 

if  (coll_checker  ==  1)  then 
check_position() 
collidex  =  xo 
endif 

End 


—  This  procedure  creates  the  hypercone  environment  and 

—  the  associated  forces  involved  with  it's  interaction. 


Procedure  funnel_force2volts() 

Begin 
volts  =1.0 

if  (coll_checker  =  l)then 

volts=0 

endif 

flagger  =  0 

if  ((force_ref_axis_dist/1000)  <=25  AND  force_ref_axis_dist  >  0)  then 

flinnelradius  =  0.25*force_ref_axis_dist 
z_check  =  abs(zf-zo)-funnel_radius 
y_check  =  abs(yf-yo)-funnel_radius 
yaw_check  =  abs(yawo)  -  funnel_radius/ 1000.0 
pitch_check  =  abs(pitcho)  -  funnel_radius/ 1000.0 
roll_check  =  abs(rollo)  -  funnel  radius/l  000.0 

if  (y_check>=0  OR  z_check>=0)  then 

volts  =  0.0 

endif 

if  (yaw_check  >=  0)  then 
flagger=flagger+l 
volts=0 
endif 

if  (pitch_check  >=  0)  then 
flagger=flagger+2 
volts=0 
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endif 

if  (roll_check  >=  0)  then 
£lagger=flagger+4 
volts=0 
endif 


SWITCH  flagger 
CASEl: 

CLIC'SET  BACK  COLOR  TO  0.01,0.99,0.99") 
CASE  2: 

CLIC'SET  BACK  COLOR  TO  0.99,0.99,0.01") 
CASES; 

CLIC'SET  BACK  COLOR  TO  0.01,0.99,0.99") 
CLIC'SET  BACK  COLOR  TO  0.99,0.99,0.01") 

CASE  4: 

CLIC'SET  BACK  COLOR  TO  0.99,0.01,0.99") 
CASE  5; 

CLIC'SET  BACK  COLOR  TO  0.01,0.99,0.99") 
CLIC'SET  BACK  COLOR  TO  0.99,0.01,0.99") 

CASE  6: 

CLIC'SET  BACK  COLOR  TO  0.99,0.99,0.01") 
CLIC'SET  BACK  COLOR  TO  0.99,0.01,0.99") 

CASE  7; 

CLIC'SET  BACK  COLOR  TO  0.01,0.99,0.99") 
CLIC'SET  BACK  COLOR  TO  0.99,0.99,0.01") 
CLIC'SET  BACK  COLOR  TO  0.99,0.01,0.99") 

DEFAULT: 

CLIC'SET  BACK  COLOR  TO  0.001,0.001,0.001") 
ENDSWITCH 


endif 

End 
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Appendix  D 


D.  1  Supporting  Software  Code  Listing:  Communication  Hub 


^!|<:(!!|!*!|'*****=l‘=|!!|<***!|t!|'*!|<**********!|<******!|'!|<>l'*He*****>|t>it!|t*>|t*!|'!|!*!|e*!(!!|«****!|<!(!=|e**** 

* 

*  OBBC_comm_hub  is  the  ethemet  communication  hub  for  the  OBBC  demonstration 

*  It  is  modified  by  Paul  Woznick  from  connect. c,  written  by  Tom  Deeter. 

*  Code  was  extracted  from  Dave  Doaks  (AFIT)  and  Matthew  Gertz  (CMU)  programs 

* 

j|t**#j|C>|C*J|t*Jt;*******J|t!|t***J|<J|<***!(<*******!|C*j|C*!|tj|c!(C*j|C!|C**!(:**J|t*!|tl|e*!|:*****>|t*!|<*****>|!!|!* 

*/ 

#include  <stdio.h> 

#include  <math.h> 

#include  <sys/types.h> 

#include  <sys/socket.h> 

#include  <netinet/in.h> 

#include  <ermo.h> 

#include  <netdb.h> 

#include  <signal.h> 

#include  <chimera.h> 

^include  <enet.h> 

^include  <string.h> 

#define  WFCJOINTS  1 
#define  WFC_QUIT  0 
#define  MAXLINE  4096 

int  sockfd; 

* 

*  Function  clean  up  will  gracefully  disconnect 

*  machines. 

void  clean_up() 

{ 

close(sockfd); 

shutdownQ; 
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exit(O); 

} 

* 

*  Function  put_data  will  send  the  data  to  the  remote 

*  non  chim  machine. 

* 

!|t!|t!|t!|C!|t>|e!|'>l<*******=l<****>l<!|'**=l‘=l‘=l‘*********!|<*****!|e>|t*>|e**!|=**!|‘/ 

put_data(sd,buf,nbytes) 
register  int  sd; 
register  char  *buf; 
register  int  nbytes; 

{ 

int  nleft,nwritten; 

nleft  =  nbytes; 

while(nleft  >  0) 

{ 

nwritten  =  write(sd,buf, nleft); 
if(nwritten  <=  0) 
return  nwritten; 
nleft  -=  nwritten; 
buf  +=  nwritten; 

} 

return  nbytes-nleft; 

} 

^**!|<*)|C*j|!*J(!l|C*J|C*********J|t******!|<!(<*!|<***=l'*****>l<!|<*********!|t>|t*5|t>l<!|e** 

* 

*  Function  get_data  will  read  the  data  from  the  remote 

*  non  chim  machine. 

* 

**********  +  ********  ***J|<*J|i****i|<JK>l<*****J|t*****************>l<**>l<*/ 


int  get_data(sd,buf,maxlen) 
register  int  sd; 
register  char  *buf; 
register  int  maxlen; 

{ 

int  n,rc; 
char  c; 
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for(n=0;n<maxlen;n++)  { 

if((rc=read(sd,&c,  1  ))==  1 ) 

{ 

*buf++  =  c; 
if(c  -=  '\n') 
break; 

} 

else  if(  rc==0) 

{ 

if(n==l)  return  0;  /*  no  data*/ 
else  break; 

} 

else 


return  -1; 

} 

*buf =  0; 
return  n; 

} 


main(argc,argv) 
int  argc; 
char  *argv[]; 

{ 

struct  sockaddrjn  cli_addr; 
struct  servent  *sp; 
struct  hostent  *hp; 
float  volts,  pi; 
char  *pname  =  argv[0]; 
int  n,  i,  count; 

char  inbuflFer[]VL\XLINE],outbuff{MAXLINE]; 
ENET  *chimenet; 
char  chimbuffer[4096]; 
int  loop, type,  size; 


if  (argc<2) 

{ 

printf("Usage:  %s  remote_host_name\n",argv[0]); 
exit(O); 

} 

while  (1) 

{ 
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* 

*  Connect  to  chimera  using  enetCreate.  Do  this  first  then 

*  start  fr.c  on  chimera. 

* 

printf("  Creating  server  tsok  on  CHIMERA\n"); 
printf(" Start  CHIMERA  NEW  communication  program\n"); 
chimenet  =  enetCreate("tsok",0); 
printf("Connected. .  .\n"); 

* 

*  Connect  to  remote  non  chim  machine  using  standard  unix  (TCP  Protocal) 

*  calls. 

* 

signal(SIGINT,clean_up); 

bzero((  char  *)&cli_addr,sizeof(cli_addr)); 
if  ((hp  =  gethostbyname(argv[l]))  ==  NULL) 

{ 

perror("unknown  host"); 
exit(O); 

} 

bcopy(hp->h_addr,(char*)&cli_addr.sin_addr,hp->h_length); 

cli_addr.sin_family  =  hp->h_addrtype; 
cli_addr.sin_port  =  htons(4903); 

printf("%d  is  the  family\n",cli_addr.sin_family); 
printf("%d  is  the  port  \n",cli_addr.sin_port); 

if((sockfd=socket(AF_INET,SOCK_STREAM,IPPROTO_TCP))  <  0) 

{ 

perror("client;  cannot  open  stream  socket"); 
exit(l); 

} 

if(connect(sockfd,  (struct  sockaddr  *)  &cli_addr,sizeof(cli_addr))  <  0) 

{ 

printf("error  #;  %d\n",  ermo); 
perror("client:  cannot  connect  to  server"); 
exit(l); 

} 
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printf("Connected  to  %s  \n",argv[l]); 

do 

{ 

size  =  sizeof(chimbuffer); 
type  =  1; 

/*  get  data  from  hardy  */ 

/*  printf("getting  data  from  hardyVn");  */ 
get_data(sockfd,outbuff,MAXLrNE); 

/*  printf("got  data\n");  */ 
n  =  strlen(outbuff); 

/*  printf("  data  to  chim  is  %s\n",outbuff);  */ 

/*  send  data  to  chimera  */ 
enet  S  end(chimenet,WF  C_JOINT  S,n,  outbuff,  0); 

/*  recieve  handshake  */ 

/*  printf("receiving  hand  shake  from  chim\n");  */ 
enetReceive(chimenet,  &type,  «&size,  chimbuffer,  0); 

/*  printf("got  handshake:  %s\n", chimbuffer);*/ 

/*  create  handshake  for  hardy  */ 

sprintf(inbuffer,  "\n"); 
n  =  strlen(inbuffer); 

/*  send  handshake  to  hardy*/ 

/*  printfC  sending  handshake  to  hardy\n");  */ 
put_data(sockfd,  inbuffer,  n) ; 

} 

while  (type  !=  WFC^QUIT); 
printf("Destroying  server... \n"); 
enetDestroy(chimenet); 

} 

} 

D.2  Supporting  Software  Code  Listing:  R/T  Microproccessor  Communication  Link 
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* 

*  This  program  modified  for  OBBC-microprocessor  communication  by  Paul  Woznick 

*  Original  code  provided  by  Tom  Deeter,  1994 

/ 

#include  <chimera.h> 

#include  <sbs.h> 

#include  <enet.h> 

#define  WFC_ACK  2 

void  poke_volts(); 

main() 

{ 


char  connection[80],inbuff[4096],outbufFer[4096]; 
int  no_conn,  type,  size; 
int  loop,n; 

float  volts, hex_volts; 
unsigned  short  out_volt; 

ENET  *enet; 

printf("  starting  prog\n"); 
no_coim=0; 

strcpy(coimection,  "tsok@kirk"); 

/*  Attach  to  an  enet  port  if  appropriate  */ 
printf("trying  to  attach\n"); 

enet  =  enetAttach(connection,  ENET_RETRIES(2)); 
printf("  attached\n"); 

poke_volts(0x07fll); 
printf("attached2\n");  - 

while(l) 

{ 


/*  get  data  from  kirk,  connect  */ 

enetReceive(enet,  &type,  &size,  inbufF,0); 
/*  kprintf("Received  %s\n",inbuff);  */ 
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/*  assign  data  to  a  buflFer  */ 


sscanf(inbuff,  "%f '  ,&volts); 

/*  kprintf("%f\n", volts);  */ 

/*  convert  float  volts  to  hexadecimal  and  send  to  D/A  */ 
hex_volts  =  4095.0-((4096.5/5.0)*(volts+2.5)); 
out_volt=(unsigned  short)  hex_volts; 

/*  kprintf("just  converted  volts  to  hex\n");  */ 
poke_volts(out_volt) ; 

/*  create  handshake  buffer  */ 

sprintf(outbuffer,  "test"); 
n=strlen(outbufFer); 

/*  send  handshake  to  kirk  */ 

/*  kprintf("send  to  kirk  %s\n",outbuffer);  */ 
enetSend(enet,  WFC_ACK,  n,  outbufFer,0); 

} 

} 

void  poke_volts(volt) 
unsigned  short  volt; 

{ 

unsigned  short  *D_A_addr; 
short  i; 

D_A_addr  =  (  unsigned  short  *)  0xFAFFF900; 
/*printf("volt=  %x\n",volt);*/ 

/*  send  all  chaimels  same  value  */ 

*(D_A_addr  +  0)  =  (unsigned  short)volt; 

} 


D.  3  Supporting  Software  Code  Listing:  Spaceball  Communication 

*  The  following  subroutine  opens  a  port  to  the  spaceball.  All  Spaceball 

*  subroutines  are  based  on  Bob  Filers  thesis  work,  converted  to  C  and 

*  modified  to  communicated  with  a  Silicon  Graphics  Indigo  Iris  workstation. 


void  open_spaceball(ttyport,  speed) 
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String  ttyport; 
int  speed; 

{ 

struct  termio  tty; 
int  status; 

if  ((SB_fd  =  open(ttyport,  0  RDWR  |  O  NDELAY))  ===  -1) 

{ 

perror("Cannot  open  Spaceball"); 
exit(l); 

} 

/*  Get  the  current  port  parameters  */ 

status  =  ioctl(SB_fd,  TCGETA,  &tty); 
if  (status  ==  -1)  ( 

fprintf  (stderr,  "Error  in  save  ioctl  call\n\n"); 

} 

/* 

*  Set  the  port  up  for; 

*  Hang  up  on  last  close 

*  eight  bits 

*  local  line 

*  enable  receiver 

*  enable  signals 

*  canonical  input 

*  user  specified  baud  rate 
*/ 

/* 

*  These  flags  set  up  the  port  for  "raw"  input.  This  allows  us  to 

*  grab  whatever  input  is  present  in  the  read  queue  regardless  of 

*  whether  the  device  is  done  sending  a  full  packet  or  not. 

*/ 


tty.c_cf[ag  =  HUPCL  |  CSS  |  CLOCAL  [  CREAD  |  speed; 

tty.c_iflag  =  IGNBRK; 

tty.e_lflag  =  0; 

tty.c_of[ag  =  0; 

tty.c_cc[VMIN]  =  0; 

tty.c_cc[VTIME]  =  0; 

status  =  ioctl  (SB_fd,  TCSETAF,  &tty); 
if  (status  ==-!){ 

fprintf  (stderr,  "Error  in  set  ioctl  call\n\n"); 
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} 


} 


/****H=**H=*=I<**=K  =I<*=I<*=|<*SKH=*****=I=  =(=**=(:  KC********^*  He****************** 


*  The  following  subroutine  initializes  the  spaceball  to  * 

*  one  of  three  modes;  voltage,  force  or  standard.  See  * 

*  user's  guide.  NOTE:  The  mode  will  be  determined  by  the  * 

*  programmer  (when  the  call  is  made).  The  simulation  * 

*  user  will  not  be  able  to  dictate  a  particular  mode  * 


void  init_spaceball(Byte  mode) 

{ 

if  ((mode  ==  SB  VOLTAGE)  ||  (mode  ==  SB  FORCE)  ||  (mode  == 
SB_STANDARD)) 

SB_mode  =  mode; 

else  { 

SBmode  =  SBFORCE; 

perror  ("Incorrect  mode  request  in  init  call\n"); 

} 

/************ t***********************************************^** 

*  The  following  subroutine  reads  in  the  raw  spaceball  data  * 

*  from  the  RS232  port  and  stores  it  in  buf  This  is  called  * 

*  only  when  the  spaceball  is  in  the  force  and  voltage  modes.  * 

**************=l<*****>|c**=|c=|c****H,**********,„:^,„,„,|,,„,„,|,*,„,„,|,,„,„,^,|,,^,^,^,^^,^^ 

int  read_raw_spaceball(Byte  *buf,int  len) 

{ 

int  count  =  0; 

/*  flush  the  input  queue  to  get  the  most  recent  data  */ 

ioctl(SB_fd,  TCFLSH,  (struct  termio  *)0); 

while(count  !=  len) 

count  =  read(SB_fd,  buf,  len); 
bufllen  - 1]  =  NULL;  /*  strip  CR/LF  */ 
retum(strlen((const  char*  )buf)); 

} 


*  The  following  subroutine  is  needed  for  the  standard  * 


104 


*  operation  mode.  * 


void  write_spaceball(Byte  *buf,int  len) 

{ 

if  (write(SB_fd,  buf,  len)  !=  len) 

{ 

perror(" Short  write  to  Spaceball"); 
exit(l); 

} 

} 

*  The  following  subroutine  reads  in  input  from  the  spaceball  * 

*  only  if  it  is  operating  in  the  standard  mode.  It  will  store  * 

*  the  incoming  data  in  buf  * 

int  read_standard(Byte  *buf,int  len) 

{ 

Byte  enq[2]; 

int  count  =  0; 
int  times  =  0; 

enq[0]  =  5;  /*  ASCII  ENQ  character  */ 

write_spaceball(enq,  1); 

#ifdefONYX 

sginap  ((long)l); 

#endif 


while  ((count  !=  len)  &&  (times  <  MAX_TIMES))  { 
count  =  read(SB_fd,  buf,  len); 
times++; 

} 

if  (times  =  500)  return  (-1); 

else  retum(strlen((const  char  *)buf)); 

} 

*  This  subroutine  formats  incoming  data.  * 
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void  parse_spaceball(SpaceballData  *sd.  Byte  *buf) 


short  button; 

sscanf^const  char  *)buf,  "%hd  %hd  %hd  %hd  %hd  %hd  %hd", 
&(sd->xtrans),  &(sd->ytrans),  &(sd->ztrans), 
«&(sd->xrot),  &(sd->yrot),  &(sd->zrot), 
&button); 
switch  (SB_mode) 

{ 

case  SB  FORCE: 

sd->button  =  ABS(button); 
break; 

case  SB  VOLTAGE: 

sd->button  =  8  -  (short)loglO((double)button); 
break; 

} 

} 


^**!it*****!|t*******!)t*  +  ***J|l***!|C*****!|t***l|e!|C*****>|t*>|t***>|tl|t****Ht** 

*  This  subroutine  formats  incoming  data  when  in  standard 

*  mode.  * 

****j|!*****j(Cl|C*>(<*!|!*!|!*!|<*!(tl|t****j|<*l(!*j|<*j(>!tl***!|<>|t>l<*l|e**!|<*>l<**!|!J|<******/ 

void  parse_standard  (SpaceballData  *sd.  Byte  *buf) 

{ 

if(bufI3]  !-37)  { 

perror  ("Incorrect  standard  read\n"); 

}  else  { 

sd->xtrans  =  buf[4]; 
sd->ytrans  =  buf[5]; 
sd->ztrans  =  buf[6]; 
sd->xrot  =  buf[7]; 
sd->yrot  =  buf{8]; 
sd->zrot  =buf[9]; 
sd->button  =  ABS(buf[10]); 

} 

} 

^!|t*j|CJ)Cl|(j|<>|C**j|t*!(:j|<***!|tJ|!****=l<********!|'******>l'********************** 

*  This  subroutine  is  the  one  called  by  the  main  program  to  * 

*  read  in  spaceball  data.  The  data  is  stored  in  sd.  * 

♦Ht***********************************************************/ 
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void  read_spaceball(SpaceballData  *sd) 

{ 

Byte  buf[SB_DATA_SIZE  +  1]; 
short  Qldbutton  =  0; 
switch(SB_mode) 

{ 

case  SB  FORCE: 

read_raw_spaceball(buf,  SB_F ORCE  SIZE) ; 

parse_spaceball(sd,  buf); 

break; 

case  SB  VOLTAGE; 

read_raw_spaceball(buf,  SB_V OLT AGE  SIZE) ; 

parse_spaceball(sd,  buf); 

break; 

case  SB_STANDARD: 

if  ((read_standard  (buf,  SB_STANDARD_SIZE))  ==-!){ 
sd->xtrans  =  sd->ytrans  =  sd->ztrans  =  0; 
sd->xrot  =  sd->yrot  =  sd->zrot  =  0; 
sd->button  =  0; 

}  else 

parse_standard  (sd,  buf); 

break; 

} 


/*  De-bounce  buttons  */ 

if  ((sd->button  >  0)  &&  (sd->button  !=  oldbutton)) 
oldbutton  ==  sd->button; 
else 
{ 

oldbutton  =  0; 
sd->button  =  0; 

} 

} 
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Appendix  E 


E.  1  Operating  Instructions:  Preparation 

1 .  Ensure  that  the  CHIMERA  operated  microprocessor  is  powered  on. 

2.  Login  to  Kirk  and  start  CHIMERA  by  typing  chim  <enter>  at  a  command  prompt. 

3 .  To  insure  that  the  D/A  board  is  cleared  of  any  voltages  type  ex  clean  <enter>  at  the 
chim  control  prompt.  CAUTION:  This  step  must  be  completed  successfully  before 
proceeding  to  step  4. 

4.  Connect  both  plugs  of  the  hand  controller  into  standard  AC  outlets. 

5.  Toggle  on  switch  for  the  CIS  DIM  6.  Watch  for  all  indicator  lights  on  the  keypad  to 
flash.  This  indicates  proper  power  up  of  the  Dim  6. 

6.  Select  TRA  button  on  the  Dim  6  keypad. 

7.  Ensure  that  the  serial  cable  from  the  Dim  6  is  connected  to  serial  port  1  on  the  Silicon 
Graphics  workstation. 

8.  Sign  on  the  Silicon  Graphics  Hardy  Workstation  (pwoznick  home  directory)  and 
create  4  shells  with  the  shell  tool.  Make  the  4  shells  as  short  as  possible  and  about  4 
inches  wide.  Drag  shells  to  each  comer  of  the  display.  The  two  windows  on  top  will  be 
your  local  shells  and  the  two  on  the  bottom  will  be  your  remote  shells. 

9.  In  the  upper  left  window  at  the  prompt  type; 

cd  deneb  <enter> 

10.  In  the  upper  right  window  at  the  prompt  type: 

cd  /usr/deneb/igrip.4d/giftware/woznick  <enter> 

11.  In  the  lower  left  window  at  the  prompt  type: 

rlogin  kirk  <enter> 
cd  /Thesis/frobmc/comm  <enter> 

12.  Repeat  step  9  for  the  lower  right  window. 

13.  Return  the  cursor  to  the  lower  left  window  and  at  the  prompt  type: 

chim  <enter> 

A  chim  control  prompt  should  appear. 

14.  In  the  upper  left  window  type: 
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/usr/deneb/igrip.4d/igrip  <enter> 

This  will  create  a  ghost  shell.  Drag  and  click  at  the  center  of  the  monitor.  Make  this 
window  as  large  as  possible  without  covering  the  other  4  window.  This  is  the  IGRIP 
workcell. 


E.2  Operating  Instructions:  Execution 

1 .  With  the  mouse,  select  the  SYS  button  from  the  tool  bar  displayed  along  the  top  of  the 
IGRIP  workcell.  Now  select  the  FILE  button  from  the  vertical  tool  bar  located  at  the 
extreme  right  of  the  workcell.  Next  select  the  APPEND  button  from  the  lower  portion  of 
the  vertical  tool  bar.  A  pop  up  window  will  open.  Use  the  mouse  to  select  Usriib.  The 
message:  File  -  Usriib  -  selected 

Config  file  appended 

2.  Now  return  the  horizontal  tool  bar  along  the  top  of  the  IGRIP  window  and  select 
LAYOUT.  Now  select  Retrieve  Workcell  from  the  vertical  tool  bar.  Pick  from  a 
resulting  pop  up  window  the  library: 

/home/pwoznick/usr/deneb/UsrlibAVORKCELLS 

Now  pick  object.  Wait  about  90  seconds  for  the  program  to  be  retrieved. 

3 .  A  message  window  will  appear.  Use  the  mouse  to  drag  and  click  the  window  to  the 
top  center  of  the  IGRIP  window,  just  below  the  horizontal  tool  bar. 

4.  Now  select  MOTION  from  the  horizontal  tool  bar.  Then  select  Simulate  from  the 
upper  portion  of  the  vertical  tool  bar. 

5.  Move  the  cursor  to  the  upper  right  'local'  window.  At  the  prompt  type: 

server_frobmc  2074  <enter> 

The  message:  object  server  started 
and:  Listening!? 

6.  Move  the  cursor  to  the  IGRIP  window  and  select  Run  from  the  upper  middle  of  the 
vertical  tool  bar.  A  pop  up  window  will  appear.  Select  done  from  the  upper  right  of  this 
window.  The  graphics  simulation  will  begin.  A  series  of  pop  up  windows  will  prompt  the 
user.  Follow  these  instructions. 

7.  The  first  prompt  will  ask  for  a  tracking  method  preference.  Using  the  SGI  keyboard 
enter  the  number  1  or  2.  1  is  V-bar  and  2  is  R-bar.  Default  is  R-bar. 

8.  The  second  prompt  will  ask  the  user  for  the  OBBC  controller  feedback  preference. 
Using  the  SGI  keyboard,  enter  numbers  1,  2,  3,  or  4.  1  is  baseline.  2  is  force  reflection.  3 
is  virtual  force  reflection  and  4  is  electronic  funneling.  Default  is  baseline  mode. 
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9.  The  third  prompt  will  be  for  a  separation  or  standoff  distance.  T5^e  500  <enter>.  This 
can  be  anything  but  to  ensure  safe  separation,  this  is  the  recommended  separation. 
Graphics  will  update  after  <enter>. 


10.  The  final  set  of  prompts  will  ask  for  initial  desired  position  commands.  This  can  be 
used  to  get  the  tracking  vehicle  in  the  direct  proximity  of  the  target  vehicle.  Suggested 
values  for  good  demonstration  and  ensuring  all  programmed  camera  views.  Enter  the 
values  depending  on  mode  and  tracking  method  from  the  table  below; 


■■1 

Modes  1, 

2&3 

Mode  4 

R-bar 

V-bar 

R-bar 

V-bar 

X 

400 

-115 

400 

-112 

y 

10 

510 

12.873 

512.64 

z 

-5 

-5 

-5.039 

-4.406 

xrot 

0 

0 

0 

0 

ililM 

0 

0 

0 

0 

1  zrot 

0 

0 

0 

0 

Table  E-1.  Initial  Input 


1 1 .  Upon  entering  the  zrot  value  the  display  will  switch  to  a  split  screen  display.  The 
cockpit  view  will  be  on  the  lower  screen  and  a  top  view  of  the  space  station  will  be  on  the 
upper  screen. 

12.  Move  the  cursor  to  the  lower  right  'remote'  window.  At  the  prompt  type; 

OBBC  hardy  <enter> 

A  message  prompting  the  initiation  of  the  comm  link  on  the  microprocessor. 

13.  Move  the  cursor  to  the  lower  left  'remote'  window  and  at  the  chim  control  prompt 

type;  ex  OBBCl  <enter> 

A  series  of  messages  should  appear  in  both  remote  windows  indicating  the  necessary 
connections  have  been  made.  The  simulation  should  begin  in  IGRIP  at  this  time. 

14.  Use  the  hand  controller  to  complete  the  approach.  Control  is  completely  natural.  Do 
to  the  controller  knob, what  you  would  like  done  to  the  tracking  vehicle. 

15.  It  may  be  helpful  to  use  the  TRA  or  ROT  and/or  DOM  buttons  on  the  keypad  of  the 
controller.  These  functions  are  described  in  chapter  3.  Additionally,  the  keypad  has  8 
function  keys.  The  functions  programmed  with  each  of  these  keys  are  described  in 
Chapter  4. 

16.  Remember  to  keep  the  cursor  in  the  IGRIP  window  to  keep  the  simulation  running. 
Also,  keep  an  eye  on  the  upper  right  local  window  for  any  communication  messages  and 
other  information.  IGRIP  is  an  interactive  graphics  environment.  Therefore  tool  buttons 


110 


located  on  the  bottom  horizontal  tool  bar  as  well  as  the  buttons  on  the  current  vertical  tool 
bar  are  available  to  enhance  the  simulation  demonstration.  Particularly  useful  buttons  are 
the  magnify  and  the  jnt  vals  buttons.  Magnify  can  be  used  to  inspect  the  mating  of  the 
spacecraft  and  joint  values  function  will  keep  you  updated  on  the  tracking  vehicles 
position. 

17.  To  end  the  simulation,  ensure  the  mouse  cursor  is  in  the  main  IGRIP  window  and 
then  simultaneously  press  the  right  and  middle  mouse  buttons.  The  simulation  will  end 
with  a  spectator  view  of  the  tracking  and  target  vehicle.  Disconnect  both  controller 
electrical  plugs. 


Ill 


Appendix  F 


F.  1  CIS  Dimension  6  Communication  Parameters  The  Dim  6  has  dip  switch  selectable 
communication  parameters,  baud  rate  and  software  protocol.  The  baud  rate  can  be  from 
300  to  19200  bps  and  is  set  at  19200  bps  for  this  thesis.  The  software  protocol  can  be  set 
to  ASCII  voltages,  ASCII  force,  ASCII  standard,  or  special  protocol.  For  this  thesis  the 
protocol  is  ASCII  standard.  Using  this  protocol,  an  imparted  force  on  the  spherical  knob 
is  converted  to  a  hexadecimal  value  between  -127  and  128.  Table  F-1  shows  the  dip 
switch  setings  of  the  spaceball  compatable  with  the  ODBC  prototype  software. 


1 

2 

6 

n 

State 

on 

off 

on 

on 

on 

Table  F-1 .  Spaceball  Dipswitch  Settings 
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